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FOREWORD 


The  Human  Factors  Technical  Area  of  the  Army  Research  Institute 
(ARI)  is  concerned  with  helping  users  and  operators  cope  with  the  ever 
increasing  complexity  of  the  battlefield  automated  systems  by  which  they 
acquire,  transmit,  process,  disseminate,  and  utilize  information.  In¬ 
creased  system  complexity  increases  demands  imposed  on  the  human  inter¬ 
acting  with  the  machine.  ARI's  efforts  in  this  area  focus  on  human  perfor¬ 
mance  problems  related  to  interactions  with  command  and  control  centers, 
and  on  issues  of  system  design  and  development.  Research  is  addressed  to 
such  areas  as  user-oriented  systems,  software  development,  information 
management,  staff  operations  and  procedures,  decision  support,  and  systems 
integration  and  utilization. 


An  area  of  special  concern  in  user-oriented  systems  is  the  improvement 
of  the  user-machine  interface.  Lacking  consistent  design  principles, 
current  practice  results  in  a  fragmented  and  unsystematic  approach  to 
system  design,  especially  where  the  user/operator-system  interaction  is 
concerned.  Despite  numerous  design  efforts  and  the  development  of  exten¬ 
sive  system  user  information  over  several  decades,  this  information  remains 
widely  scattered  and  relatively  undocumented  except  as  it  exists  within  and 
reflects  a  particular  system.  The  current  effort  is  dedicated  to  the 
development  of  a  comprehensive  set  of  Human  Factors  guidelines  and  eval¬ 
uation  criteria  for  the  design  of  user/operator  transactions  with  battle¬ 
field  automated  systems.  These  guidelines  and  criteria  are  intended  to 
assist  proponents  and  managers  of  battlefield  automated  systems  at  each 
phase  of  system  development  to  select  the  design  features  and  operating 
procedures  of  the  human -computer  interface  which  best  match  the  require¬ 
ments  and  capabilities  of  anticipated  users/operators. 


Research  in  the  area  of  user-oriented  systems  is  conducted  as  an 
in-house  effort  augmented  through  contracts  with  uniquely  qualified 
organizations.  The  present  effort  was  conducted  in  collaboration  with 
personnel  from  Synectics  Corporation  under  contract  MDA903-80-C-0094. 
The  effort  is  responsive  to  requirements  of  Army  Project  2Q263744A793, 
Human  Performance  Effectiveness  and  Simulation,  and  to  special  requirements 
of  the  U.S.  Army  Combined  Arms  Combat  Developments  Activity  (CACDA),  Fort 
Leavenworth,  Kansas. 


JOSEPH  ZEUDVER 
Technical inrector 
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DESIGN  GUIDELINES  AND  CRITERIA  FOR  USER/ OPERATOR  TRANSACTIONS  WITH  BATTLE 
FIELD  AUTOMATED  SYSTEMS  VOLUME  II:  TECHNICAL  DISCUSSION 

EXECUTIVE  SUMMARY 


Requirement : 

To  develop  a  comprehensive  set  of  human  factors  guidelines  and  criteria 
for  the  design  of  user/operator  transactions  in  battlefield  automated 
systems  for  use  by  human  factors  specialists  and  system  proponents, 
managers,  and  developers. 


Procedure : 

To  provide  data  for  a  baseline  functional  description  of  user/operator 
transactions  in  battlefield  automated  systems,  user/operator  interactions 
in  a  series  of  systems  were  analyzed  using  a  Transaction  Feature  Analysis 
technique.  Data  were  collected  during  interviews  with  system  experts  and 
reviews  of  system  documentation.  Transactions  were  then  compared  across 
systems  using  a  Transaction  Compatability  Analysis  technique.  Results  of 
these  analyses  formed  the  data  base  for  development  of  preliminary  guide¬ 
lines  and  criteria. 


Findings : 

Results  of  the  system  analyses  support  two  conclusions:  (1)  battle¬ 
field  automated  systems  are  highly  variable  on  a  wide  range  of  attributes 
related  to  user/operator  transactions;  and  (2)  while  examples  of  good 
design  appear  in  some  of  the  newer  systems,  in  general  battlefield  auto¬ 
mated  systems  are  characterized  by  design  features  that  are  incompatible 
with  human  capabilities  and  limitations.  In  addition,  review  of  the  human 
factors  literature  demonstrated  that  results  of  that  research  are  inade¬ 
quate  to  support  design  of  good  user/operator  transactions  in  automated 
systems.  Data  derived  through  the  transaction  feature  and  compatability 
analyses  served  the  project  well  as  the  data  base  on  which  the  provisional 
guidelines  and  criteria  are  drawn. 


Utilization  of  Findings: 

Findings  from  the  analysis  of  individual  systems  may  be  useful  to 
proponents  in  specifying  user/operator  requirements  for  future  system 
evolution.  In  this  project,  the  findings  were  incorporated  in  a  data  base 
on  human  factors  requirements  which  provided  the  "real  world"  foundation 
for  development  of  the  provisional  guidelines  and  criteria  presented  in 
volume  IV  of  this  report.  The  provisional  guidelines  and  criteria  will  be 
utilized  as  the  basis  for  development  of  the  prototype  handbook. 
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INTRODUCTION 


This  document  contains  a  technical  discussion  of  issues 
project  activities,  results,  and  products  of  the  first  phase 
project  to  develop  guidelines  and  criteria  for  user/operator 
with  U.S.  Army  battlefield  automated  systems. 


considered, 
in  a  three-phase 
transactions 


BACKGROUND 

Information  has  always  been  a  precious  commodity  on  the  battlefield, 
and  commanders  have  always  wished  for  better  and  faster  ways  to  obtain  it. 
Modem  technology  is  providing  increasing  numbers  of  sensors  and  data  collec¬ 
tion  methods  to  meet  this  need.  This  effort  has  been  so  successful  that  the 
battlefield  of  today  is  an  environment  rich  in  information.  Indeed,  recent 
years  have  seen  an  "information  explosion"  on  the  battlefield  that  may  well 
rival  the  one  in  the  private  sector  that  has  received  so  much  attention. 

So  plentiful  has  it  become  that  the  sheer  volume  of  information  pouring  into 
tactical  operations  centers  threatens  to  overwhelm  the  capabilities  of 
commanders  and  their  staffs  to  absorb  and  interpret  it. 

The  ability  to  manage  the  battlefield  information  explosion — to  process 
information  accurately  and  quickly— might  well  provide  a  force  multiplier 
approaching  in  importance  the  element  of  surprise.  Unfortunately,  this  force 
multiplier  will  not  be  achieved  merely  by  assigning  more  and  more  personnel 
to  data  processing  tasks  (thereby  making  fewer  personnel  available  for  other 
urgent  duties) .  Recognizing  this  fact,  the  Army  has  devoted  increasing  re¬ 
sources  to  automation.  Currently,  more  than  60  computer-based  information 
processing  systems  are  in  production,  development,  or  concept  definition  for 
deployment  at  corps  and  subordinate  echelons.  As  shown  in  Figure  1,  these 
automated  systems  eventually  will  support  most  of  the  Army's  battlefield 
functional  areas. 


PERSONNEL  ISSUES  IN  BATTLEFIELD  AUTOMATION 

The  proliferation  of  battlefield  automated  systems,  however,  carries 
with  it  potentially  severe  problems.  Many  of  these  problems  relate  to  the 
personnel  who  will  staff  them.  At  least  three  areas  can  be  identified  in 


ARMY  BATTLEFIELD  AUTOMATED  SYSTEM  CATEGORIZATION 


Figure  1.  Army  Battlefield  Automated  Systems,  Categorized  by  Status  in  the  System  Life  Cycle 
and  by  Battlefield  Functional  Area,  as  of  14  May  1980. 


which  such  problems  arise:  the  human-computer  interface,  coordination  among 
system  developers,  and  the  skill-demand  mismatch. 

Human-Computer  Interface 

System  developers  have  tended  to  regard  human  beings  as  highly  adaptable 
to  the  idiosyncracies  of  their  systems.  They  have  thus  felt  free  to  concen¬ 
trate  design  and  development  resources  almost  exclusively  on  the  computing 
hardware  and  on  data  communication,  reduction,  and  analysis  software.  Rela¬ 
tively  little  effort  has  centered  on  the  human  engineering  features  of  the 
equipment,  and  even  less  on  the  human  factors  features  of  the  software  inter¬ 
face,  such  as  control  methods,  data  entry  assistance,  display  formats,  or 
error  handling  procedures. 

Often,  the  result  has  been  a  human-computer  interface  that  is  less  than 
optimal  from  the  user's/operator's  point  of  view.  Long  lists  of  data  codes 
impose  heavy  memory  burdens.  Densely  packed  input  and  output  displays  strain 
perceptual  abilities.  Complex  transactions  tax  cognitive  processes.  Ambig¬ 
uous  error  messages  inhibit  diagnostic  and  correction  efforts.  The  consequences 
of  these  and  other  undesirable  design  features  are  increased  error  rates  and 
reductions  in  data  processing  bates — and  system  effectiveness  less  than  required 
and  expected. 

Coordination  Among  System  Developers 

Recently,  system  proponents  and  system  developers  have  begun  to  show 
increased  awareness  of  the  significance  of  human  characteristics  for  the  design 
of  battlefield  automated  systems.  As  will  be  demonstrated  in  this  report, 
however,  there  is  no  adequate  technology  readily  available  to  guide  their 
efforts  to  take  those  characteristics  into  account  in  designing  the  human- 
computer  software  interface.  Moreover,  Army  battlefield  automated  systems 
typically  are  developed  independently,  with  little  or  no  coordination  among 
proponents  or  developers.  Consequently,  lessons  learned  during  development 
of  one  system  seldom  find  application  in  other  systems.  More  importantly,  con¬ 
figurations  and  procedures  that  are  quite  similar  conceptually  appear  quite 
different  when  implemented  in  various  systems.  For  example,  updating  a  data 
file  is  a  function  common  to  many  battlefield  automated  systems,  whether  they 
support  personnel  administration,  intelligence,  maneuver  control,  or  logistics. 
However,  that  function  may  be  performed  in  radically  different  ways  on  diff¬ 
erent  systems,  depending  on  design  decisions  such  as: 
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a.  The  selection,  arrangement,  and  labeling  of  function  keys. 

b.  The  structures  of  display  formats. 

c.  The  conventions  adopted  for  naming  the  updating  operations. 

d.  The  sequence  in  which  those  operations  are  performed. 

The  lack  of  coordination  among  proponents  and  developers  imposes  a 
special  penalty  upon  users/operators  who  transfer  from  one  system  to  another. 
Normally,  of  course,  increased  experience  leads  to  improved  performance.  But 
when  an  experienced  user/operator  moves  from  a  familiar,  well-known  system  to 
a  new  one,  very  often  previously  acquired  skills  do  not  transfer.  Equipment 
arrangements  differ,  procedures  differ,  formats  differ,  and  codes  differ. 

Thus,  instead  of  facilitating  performance  on  the  new  system,  prior  experience 
may  actually  degrade  that  performance. 

Ski 11 -Demand  Mismatch 

In  turning  initially  to  automation,  American  business  and  industry 
anticipated  that  computers  would  reduce  personnel  skill  requirements.  As  it 
happened,  more  often  than  not,  precisely  the  opposite  effect  occurred;  maxi¬ 
mum  effectiveness  of  complex  computer  technology  required  greater  skills  than 
did  the  manual  methods  the  technology  replaced.  The  Army  has  had  a  similar 
experience — at  a  time  when  its  skills  pool  has  been  contracting  rather  than 
expanding. 

The  Army  confronts  an  unpleasant  prospect.  Force  levels  doubtless  will 
not  increase  substantially  in  the  near  future.  At  the  same  time,  increasing 
numbers — and  increasing  complexity — of  battlefield  automated  systems  demand 
larger  numbers  of  skilled  personnel.  These  facts  suggest  that  a  time  will 
come  when  insufficient  personnel  with  the  necessary  skills  will  be  available 
to  staff  all  the  systems  that  have  been  introduced.  Figure  2  illustrates 
this  possibility. 

A  Possible  Solution 

The  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences  (ARI) 
has  proposed  a  solution  to  the  problems  described  above.  That  solution  is 
to  provide  guidance  for  the  design  of  human-ccmputer  software  interfaces 
that  capitalize  on  human  capabilities  and  compensate  for  human  limitations. 
Such  guidance  would  help  greatly  to  optimize  the  design  of  the  software  inter- 
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Figure  2 .  Is  there  a  point  where  we  may  have  more  systems  in  the  acquisition 
cycle  than  we  have  people  available  to  staff  and  maintain  them? 

face  from  the  user ' s /operator' s  point  of  view.  Consistently  applied  across 
systems,  it  would  facilitate  coordination  among  proponents  and  developers, 
thereby  alleviating  the  problem  of  skills  transfer  among  systems.  And  finally, 
that  guidance  would  help  to  make  the  software  interface  simpler  and  easier 
to  use,  minimizing  the  skills-demand  mismatch  in  the  process. 

PURPOSES  OF  THE  PROJECT 

This  project  has  two  major  purposes: 

a.  To  develop  guidelines  for  the  design  of  user/operator  trans¬ 
actions  with  battlefield  automated  systems. 

b.  To  develop  evaluation  criteria  for  determining  the  efficacy 
of  transaction  design. 

Both  guidelines  and  criteria  will  be  written  in  language  and  formats  suit¬ 
able  for  system  proponents,  developers,  and  designers  as  well  as  for  human 
factors  specialists.  In  addition,  guidelines  and  criteria  will  be  developed 
for  each  stage  of  the  system  life  cycle. 
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OBJECTIVES 


To  fulfill  these  purposes,  ARI  formulated  three  principal  objectives  for 
the  project's  initial  phase: 

a.  Analysis  of  human-computer  interactions  in  battlefield 
automated  systems. 

b.  Development  of  provisional  guidelines  and  criteria  for  the 
design  of  user/operator  transactions. 

c.  Identification  of  critical  problems  and  deficiencies  in 
human-computer  interactions. 

These  objectives  are  described  more  fully  below. 

Analyze  Human-Computer  Interactions 

A  "real-world"  basis  for  guideline  and  criteria  development  requires 
knowledge  about  the  characteristics  of  battlefield  automated  systems,  with 
particular  emphasis  on  those  features  that  affect  user/operator  transactions. 
Therefore,  a  survey  would  be  conducted  of  battlefield  automated  systems.  This 
survey  would  be  conducted  in  two  portions.  First,  available  data  on  all 
systems  would  be  reviewed  to  provide  an  initial  baseline  of  information.  Then, 
selected  systems  would  be  analyzed  in  greater  depth  to  validate  the  baseline 
and  provide  greater  detail  regarding  user/operator  transactions. 

Develop  Guidelines  and  Criteria 

Guidelines.  Working  on  the  baseline  established  by  analysis  of  actual 
systems,  guidelines  must  be  developed  to  assist  proponents  and  developers  to  select 
interface  features  best  matching  the  characteristics  of  anticipated  users/operators. 
This  effoit  could  also  draw  on  the  information  available  in  the  research 
literature.  A  fundamental  requirement  for  achieving  this  objective  would  be 
to  couch  guidelines  in  terms  free  of  psychological  jargon,  using  language 
understandable  to  proponents  and  developers  as  well  as  human  factors  special¬ 
ists.  Further,  guidelines  must  be  explicit  and  useable.  For  example,  "make 
displays  easy  to  read"  is  an  unacceptable  guideline;  it  does  not  indicate 
specifically  how  a  display  can  be  made  easy  to  read.  "Use  upper  case  char¬ 
acters  only  to  begin  sentences  or  proper  nouns,  or  to  highlight  important 
words  or  phrases"  would  be  more  appropriate.  This  statement  is  not  yet 
proposed  as  an  actual  guideline.  Nonetheless,  it  illustrates  the  specificity 
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required  to  tell  a  designer  how  to  "make  displays  easy  to  read."  Preliminary 
guidelines  of  this  type  would  be  a  major  product  of  the  project's  first  phase. 

Criteria.  To  provide  the  means  to  evaluate  transaction  feature  design 
from  the  point  of  view  of  the  user/operator,  criteria  are  required  for  each 
category  of  design  guidelines  and  for  each  stage  of  the  system  development 
process.  These  evaluation  criteria  must  provide  objective  procedures  and  tech¬ 
niques  for  assessing  the  degree  to  which  candidate  software  interface  features 
and  operating  procedures  meet  the  human  factors  requirements  embodied  in  the 
guidelines . 

Identify  Problems 

Finally,  the  first  phase  of  the  project  would  identify  the  areas  of  the 
human-computer  software  interface  in  which  significant  problems  and  deficiencies 
exist  in  the  human  factors  technology.  This  task  would  draw  upon  the  results 
of  the  first  two  tasks  to  identify  those  areas  most  critical  to  successful 
system  performance;  to  define  issues  such  as  error  sources  and  (where  possible) 
frequencies;  to  specify  the  implications  of  problem  areas  for  transaction  fail¬ 
ure  an^.  system  failure;  and  to  illustrate  problems  and  deficiencies  with 
examples  from  actual  battlefield  automated  systems. 

APPROACH 

To  accomplish  its  objectives,  the  project  involved  three  major  tasks  dur¬ 
ing  the  first  year.  The  first  of  these  tasks  identified  and  analyzed  human- 
computer  interactions  in  battlefield  automated  systems .  The  task  began  with  an 
initial  survey  of  the  general  characteristics  of  these  systems,  and  encompassed 
as  many  systems  as  resources  permitted.  The  final  part  of  the  task  focused  on 
in-depth  analyses  of  five  selected  systems.  The  second  task  required  develop¬ 
ment  of  a  set  of  provisional  design  guidelines  and  evaluation  criteria.  These 
materials  will  be  refined  and  expanded  to  provide  a  prototype  proponent/ 
developer  handbook  later  in  the  project.  The  third  task  involved  performing  an 
analysis  of  information  gathered  during  the  first  task  and  of  guidelines  and 
criteria  developed  during  the  second  task.  This  analysis  identified  critical 
problem  areas  and  deficiencies  in  the  human-computer  software  interface  that 
controls  user/operator  transactions  in  battlefield  automated  systems. 
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ANALYSIS  OF  HUMAN -COMPUTER  INTERACTIONS 


INITIAL  SURVEY 

To  identify  and  analyze  human-computer  interactions  in  battlefield 
automated  systems,  a  survey  was  undertaken  of  all  such  systems.  This  survey 
encompassed  documentation  from  the  Battlefield  Automation  Management  Plan 
(BAMP)  and  the  Army  Battlefield  Interface  Concept  (ABIC) ,  and  a  data  collec¬ 
tion  technique  devised  for  this  task. 

Battlefield  Automation  ilanaqement  Plan  (BAMP) 

The  BAMP  was  administered  by  the  Battlefield  Automation  Management 
Directorate  (BAMD)  of  the  Combined  Arms  Combat  Developments  Activity  (CACDA) 
at  Fort  Leavenworth,  Kansas  until  CACDA  was  reorganized  in  1979.  As  orig¬ 
inally  conceived,  the  BAMP  provided  for  periodic  review  of  all  battlefield 
automated  systems.  ARI  and  Synectics  initially  believed  that  a  large  volume 
of  data  had  been  collected  on  all  or  most  battlefield  automated  systems  as 
part  of  the  BAMP  review  process.  These  data  presumably  would  include  infor¬ 
mation  about  the  designs  and  operational  characteristics  of  these  systems. 
Much  of  this  information  could  be  expected  to  relate  to  user/operator  func¬ 
tions  and  requirements. 

Interviews  with  former  BAMD  personnel  at  Fort  Leavenworth,  and  examina¬ 
tion  of  information  available  in  Alexandria,  Virginia  revealed  that  this  was 
not  the  case.  The  only  materials  found  were  synopses  of  BAMP  system  reviews. 
Table  1  shows  the  headings  of  the  standard  nine-paragraph  format  of  the 

Table  1 

Format  of  Synopses  of  BAMP  Reviews  of 
Battlefield  Automated  Systems 


•  Brief  System  Description 
s  Information  Shortfalls 

s  Operational  Design  Criteria 
e  Life  cycle  Cost 
e  Personnel  Inpact 

•  Ccemo  Impact 

e  System  Strengths  and  Weaknesses 
e  General  Remarks 
e  BRIO'S  Recoemendations 

•  References 
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synopses.  Figure  3  illustrates  the  form  used  to  record  information  obtained 
from  the  examination  of  these  synopses.  The  full  set  of  such  forms  is  pre¬ 
sented  in  Appendix  A.  Figure  3  also  illustrates  that  the  BAMP  synopses 
did  not  focus  sufficiently  on  human  factors  issues  to  meet  the  requirements 
of  this  task.  For  example,  they  provided  no  human  performance  data  such  as 
error  rates  or  times  required  to  complete  transactions.  Further,  they  pro¬ 
vided  no  data  on  the  types  of  transactions  to  be  performed  by  the  users/ 
operators  in  various  battlefield  automated  systems.  Finally,  human  engineer¬ 
ing  data  in  the  synopses  focused  exclusively  on  maintenance  issues.  Obviously, 
such  issues  are  critically  important  to  successful  system  performance.  How¬ 
ever,  they  are  beyond  both  the  scope  and  the  resources  of  this  project. 

Army  Battlefield  Interface  Concept  (ABIC) 

The  major  purpose  of  the  ABIC  is  to  define  a  high  level  architecture 
for  Army  battlefield  automated  systems.  As  such,  documentation  of  the  concept1 
contains  considerable  information  about  these  systems.  However,  this  infor¬ 
mation  provides  a  broad  overview  of  systems,  rather  than  specific,  detailed 
information  about  particular  issues  in  individual,  systems.  Figure  4  illus¬ 
trates  the  form  used  to  record  types  of  unclassified  information  obtained 
from  ABIC  79  documentation.  The  full  set  of  data  is  presented  in  Appendix  B. 

As  with  the  BAMP,  the  ABIC  79  did  not  provide  substantitive  data  on  human 
factors  issues  of  concern  to  this  project,  such  as  transaction  types,  error 
rates,  or  times  required  to  complete  transactions. 

Transaction  Feature  Analysis 

Given  the  lack  of  suitable  data  from  these  sources,  meeting  the  project's 
information  needs  required  development  of  a  special  data  collection  instrument. 
The  result  of  that  effort,  the  Transaction  Feature  Analysis  technique,  met 
that  need.  Indeed,  the  technique  became  the  project's  first  product,  since  it 
also  has  utility  in  the  system  development  process,  as  will  be  shown  later  in 
this  report. 


l/Army  Battlefield  Interface  Concept  (ABIC)  79  (U) .  ACN  47635,  Headquarters 
Department  of  the  Army.  Washington,  D.C.  20310,  1979.  CONFIDENTIAL. 
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Figure  3.  Format  of  the  data  recording  form  used  for  examination  of  BAMP  system  synopses,  illustrating 
types  of  information  obtained. 
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Format  of  Data  Recording  Folth  Used  in  Examination  of  ABIC  79,  Illustrating  Types  of  Information 


The  Transaction  Feature  Analysis  technique  consists 
narrative  description  of  a  system  design  feature  and  its 
performance.  The  headings  of  the  six  steps  are  shown  in 
cribed  in  detail  below. 


of  a  six-step 
effect  on  system 
Table  2,  and  des- 


Table  2 

Format  of  the  Transaction  Feature  Analysis  Technique 


•  TRANSACTION  ’'EATURE 

•  DESCRIPTION 

•,  BEHAVIORAL  IMPLICATION 

•  TRANSACTIONAL  IMPLICATION 

•  CONSEQUENCE ( s ) 

•  RECOMMENDED  RESOLUTION 


Transaction  Feature.  The  transaction  feature  is  a  description  of  a 
generalized  designator  of  a  class  of  transactions.  It  provides  a  simple 
definition  of  the  transaction  type.  For  example: 

Constraints  in  updating  multivalued  fields. 

Description.  The  description  explains  how  the  transaction  feature 
works  and  what  it  does,  in  simple  operational  terms.  For  example: 

Many  of  the  fields  in  the  data  files  are  multivalued 
fields.  During  updating  functions,  the  user /operator 
has  the  capability  to  add  new  items  to  these  fields, 
or  to  change  or  delete  existing  items  in  a  field.  If 
the  user/operator  wishes  to  delete  only  a  portion  of 
a  field,  but  neglects  to  specify  the  particular  items 
to  be  deleted,  then  execution  of  a' change  or  delete 
command  will  delete  all  items  in  that  field. 

Behavioral  Implications.  Behavioral  implications  involve  the  trans¬ 
action  features'  impact  on  the  user/operator.  This  section  describes  what 
the  user/operator  must  do  (and  must  not  do)  to  complete  the  transaction 
successfully.  It  also  describes  the  demands  the  feature  imposes  on  the 
user/operator  in  terms  of  memory  burden,  skill  requirements,  error  likeli¬ 
hood,  and  other  performance  issues.  For  example: 

In  updating  only  a  portion  of  a  data  field,  the  user/ 
operator  must  remember  to  specify  precisely  the  items 
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to  be  changed  or  deleted.  This  requirement  imposes 
an  excessive  memory  burden  on  the  user / operator ,  and 
provides  an  unnecessary  source  of  performance  error. 

Transactional  Implications.  In  contrast  to  the  behavioral  implications, 
t.iis  section  describes  the  feature's  effect  on  system  operations.  This 
effect  is  described  in  operational  terms  such  as  the  system's  capability  to 
detect  errors  or  the  time  required  to  complete  transactions.  For  example: 

Complete  data  removal  from  an  entire  field  is  a  legal 
operation.  The  system  therefore  cannot  determine  when 
such  removal  constitutes  an  error. 

Consequences  of  the  Problem.  In  this  step,  the  transaction  feature's 
impact  on  the  system's  effectiveness  is  described  in  operational  terms.  For 
example: 

Data  base  integrity  will  be  eroded  by  inadvertent  loss 
of  relevant  data  items.  Reports  may  lack  significant 
or  even  vital  information.  The  commander's  picture  of 
the  battlefield  may  be  distorted. 

Recommended  Resolution.  Finally,  specific  pragmatic  actions  are  sug¬ 
gested  to  improve  the  performance  of  user/operator  transactions  with  the 
computer.  For  example: 

Modify  system  software  to  require  the  user/operator  to 
enter  a  positive  indication  of  his/her  intention  to  delete 
an  entire  data  field.  For  example,  reouire  the  user/ oper¬ 
ator  to  enter  "DELETE  (field  name)  ALL "  when  the  entire 
field  is  to  be  deleted. 

Alternatively,  if  a  feature  is  described  that  cannot  currently  be  corrected 
because  of,  say,  cost  considerations,  the  recommended  resolution  might  apply 
_o  future  versions  of  the  system  or  to  similar  systems  presently  under 
development.  The  analysis  merely  describes  the  recommended  resolution,  of 
course,  since  development  personnel  are  in  the  best  position  to  evaluate  the 
tradeoffs  inherent  in  the  situation. 

Using  the  Transaction  Feature  Analysis  technique,  a  survey  was  con¬ 
ducted  of  nine  Army  battlefield  automated  systems,  two  USMC  systems  having 
significant  features  in  common  with  Army  systems,  and  a  Rand  Corporation 
system  developed  for  intelligence  applications  (Table  3) .  Observations  of 
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Table  3 


Systems  Surveyed  with  Transaction 
Feature  Analysis  Technique 


TACFIRE 

TOS2 

TCT 

OS  4  AUTO  RUN  BOOK 
OLD  ED 

PHOENIX  AUTO  RUN  BOOK 


IISS 

BCS 

MAGIS  (USMC) 
SDA  (USMC) 
ISIS  (RAND) 
DAS  3 


these  systems  were  recorded  on  a  data  collection  form  designed  for  this  pur¬ 
pose  (Figure  5) .  Exanoles  of  brief  reports  resulting  from  this  surey  are 
presented  in  Appendix  C.  These  examples  are  included  for  illustration  only; 
findings  of  the  survey  were  integrated  with  those  of  analyses  described 
below. 

ANALYSES  OF  SELECTED  SYSTEMS 

Validation  of  the  data  obtained  from  the  survey  required  more  detailed 
human  factors-oriented  analysis  of  the  user-computer  software  interface  in 
battlefield  automated  systems.  Such  analyses  also  would  broaden  the  baseline 
of  information  about  user/operator  transactions  initially  established  by  the 
survey.  The  time  and  resources  available  to  the  project  precluded  analysis 
of  a  large  number  of  systems,  however,  so  a  sample  was  selected  from  the 
systems  listed  in  Figure  1. 

Selection  Criteria 

Two  criteria  governed  the  selection  of  systems  for  analysis: 

a.  A  system  had  to  be  chosen  from  each  of  the  stages  of  the 
system  life  cycle:  concept  definition,  validation/'.evelop- 
ment,  and  production/deployment. 

b.  The  selected  systems  had  to  represent  different  Army  battle¬ 
field  functional  areas. 

The  three  systems  initially  selected  met  these  criteria,  and  were  accessible 
for  analysis: 
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TRANSACTION  FEATURE  ANALYSIS  FORM  I  I  TRANSACTION  FEATURE  ANALYSIS  FORM  (Continued) 


Figure  5.  Data  Collection  Form  Used  to  Record  Observations  of  Battlefield  Automated  System.' 


a.  The  Division  Level  Data  Entry  Device  (DLDED)  is  presently 
in  concept  development,  and  is  designed  for  use  both  in 
personnel  administration  and  logistics. 

b.  The  Tactical  Computer  Terminal  (TCT) ,  a  system  currently 
in  validation/development,  will  support  the  maneuver 
control  area. 

c.  The  Tactical  Fire  Direction  System  (TACFIRE)  is  in  pro¬ 
duction/deployment,  and  is  a  field  artillery  system. 

After  these  systems  were  selected,  two  additional  systems  were  included  in 
the  sample. 

The  DS4  Automated  Run  Book  was  added  by  invitation  from  the  system's 
developers.  The  Run  Book  will  provide  a  software  interface  between  functional 
supply  personnel  and  the  DS4  supply  data  processing  software  package  that  runs 
on  the  DAS  3  computer. 

The  Intelligence  Information  Subsystem  (IISS)  was  added  to  the  sample 
as  an  additional  task  to  the  contract.  The  IISS  is  a  system  currently  in 
validation/development  for  the  intelligence  functional  area.  Including  these 
two  systems  broadened  the  analysis  sample  and  also  provided  additional  data 
for  the  baseline  on  user/operator  transactions. 

Data  Collection 

Data  were  gathered  by  two  principal  methods.  First,  ARI  and  Synectics 
personnel  interviewed  subject  matter  experts  and/or  developer  personnel  at  Fort 
Benjamin  Harrison,  Fort  Lee,  and  Fort  Belvoir  (DLDED  and  DS4  Automated  Run  Book); 
at  Forth  Monmouth  and  the  MELPAR  building  near  Washington,  D.C.  (TCS/TCT) ;  at 
Fort  Sill,  Oklahoma  (TACFIRE);  and  in  USAREUR  (IISS).  Where  possible,  visits  to 
installations  included  observations  of  the  system.  Second,  they  studied  available 
documentation  to  extract  information  about  system  design  features  and  operat¬ 
ing  procedures  that  would  affect  user/operator  transactions  with  the  system’s 
computer.  During  both  interviews  with  subject  matter  experts  and  studies  of 
system  documentation,  extensive  use  was  made  of  the  Transaction  Feature  Anal¬ 
ysis  technique  described  above. 

Classification  Scheme 

During  both  the  initial  survey  and  subsequent  more  detailed  analyses  of 
systems,  observations  were  recorded  on  a  wide  range  of  design  features  that 
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would  affect  user/operator  transactions.  Comparing  these  transaction  features 
both  within  a  single  system  and  among  different  systems  was  necessary  to  per¬ 
mit  identification  of  problems  and  deficiencies  that  are  common  to  systems  as 
well  as  those  unique  to  a  particular  system.  Such  comparisons  would  be 
greatly  facilitated  by  some  kind  of  classification  scheme  that  would  organize 
observations  in  a  coherent  and  consistent  manner. 

Existing  structures.  The  literature  reporting  research  on  the  human- 
computer  interface  contains  several  such  organizing  structures.  Engle  and 
Granda1 ,  Ramsey  and  Atwood2,  and  Smith3  are  among  those  who  have  devised 
schemes  to  classify  their  own  design  recommendations.  Inspection  of  these 
schemes  shows  that,  while  there  are  common  features,  none  of  the  structures 
found  in  the  literature  is  consistent  with  the  others.  Doubtless,  consistency 
will  emerge  in  this  relatively  new  field  of  research  as  work  continues.  Doubt¬ 
less  also,  different  levels  of  taxonomy  will  be  developed  to  meet  differing 
requirements.  In  the  meantime,  the  existing  structures  appeared  inappropriate 
for  this  project  because  they  were  judged  to  be  too  detailed  or  too  psychologic¬ 
ally  oriented  for  its  purpose. 

Structure  adopted  for  this  project.  Analysis  of  data  collected  early  in 
the  survey  yielded  a  tentative  pattern  of  transaction  features.  As  data  collec¬ 
tion  and  analysis  continued,  the  initial  structure  was  modified,  resulting 
finally  in  the  categories  shown  in  Table  4.  This  scheme  is  not  entirely  satis- 


•l /Engle,  S.E.  and  Granda,  R.E.  Guidelines  for  man/display  interfaces. 
Technical  Report  TR  00.2720.  Poughkeepsie,  New  York:  IBM  Poughkeepsie 
Laboratory,  December  1^75 . 

Z/Ramsey,  H.R.  and  Atwood,  M.E.  Human  factors  in  computer  systems:  A 
review  of  the  literature.  Technical  Report  SAI-79-111-DEN.  Englewood, 
California:  Science  Applications,  Inc.,  September  1979. 

3/Smith,  S.D.  Man-machine  interface  (MMI)  requirements  definition  and  design 
guidelines:  A  progress  report.  Technical  Report  MTR-8134:  The  Mitre 
Corporation,  Bedford,  Massachusetts,  September  1980. 
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Table  4 


Categories  of  Design  Features  Affecting  User/Operator  Trans¬ 
actions  with  Battlefield  Automated  Systems 


1 .  CONTROL  METHODS 


1.1  Command  Languages 

1.2  Menus 

1.3  Function  Keys 

1.4  Hybrid  Methods 

1.5  Prompts/HELPS 

2.  DISPLAY  FORMAT 


2.1  Fixed  Alphanumeric  Displays 

2.2  Variable-Length  Alphanumeric  Displays 

2.3  Graphic  Displays 

2.4  Highlighting 

3.  DATA  ENTRY  AND  HANDLING 


3.1  Information  on  Legal  Entries 

3.2  Unburdening  of  Input 

3.3  Interrupts  and  Work  Recovery 

3.4  Manipulating  stored  Data 


4.  MESSAGE  COMPOSITION  AIDS 


4.1  System  Design  Features 

4.2  Format  for  Alphanumeric  Messages 

4.3  Graphic  Messages 

5.  DATA  RETRIEVAL  ASSISTANCE 

5.1  Query  Method 

5.2  Query  Structure 

6.  GLOSSARIES 

6. 1  Standard  Terms 

6.2  Character  Sets  and  Labels 

6.3  Glossary  Availability  and  Use 

6.4  Abbreviation  and  Coding 

7.  ERROR  HANDLING 


7.1  Prevention 

7.2  Detection 

7.3  Feedback 

7.4  Correction/Recovery 

8.  USER/OPERATOR  CONFIGURATION 


8.1  Operator (si  Only 

8.2  Operatorlsl  and  User(s) 

8.3  Combined  User/Operator 

8.4  User  and  Operator  Chains 
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factory,  since  transaction  features  sometimes  are  difficult  to  assign  to  one 
category  as  opposed  to  another.  Probably,  it  will  be  modified  as  work  pro¬ 
ceeds  on  the  prototype  guideline  and  criteria  handbook  during  the  second  phase 
of  the  project.  Even  so,  the  current  list  of  transaction  features  in  Table  4 
provides  a  convenient  structure  for  organizing  the  observations  recorded 
during  the  survey  and  analyses  of  systems. 

Presentation  of  Findings 

For  each  system  analyzed  in  detail,  a  separate  report  was  prepared. 

Each  report  describes  general  hardware  and  software  features  of  the  system 
that  relate  to  the  human-computer  interface.  The  remainder  of  the  report 
describes  the  analysis  of  specific  system  software  interface  features  that 
affect  the  performance  of  user/operator  transactions.  Transaction  feature 
analyses  of  these  specific  features  were  summarized  according  to  the  cate¬ 
gories  in  Table  4,  and  the  feature  analyses  themselves  are  provided  in  an 
Appendix  to  the  report. 

The  separate  reports  do  not  consolidate  information  gathered  for  the 
various  systems.  Rather,  each  is  a  separate,  stand-alone  entity,  and  is 
bound  separately  in  Volume  III  of  the  Final  Report.  This  method  of  pre¬ 
sentation  permits  persons  who  are  particularly  interested  in  the  analysis  of 
a  specific  system  to  access  the  relevant  report  conveniently.  Integration 
of  the  results  and  discussion  of  their  relevance  to  design  guidelines  and 
evaluation  criteria  begin  immediately  below. 

RESULTS 

Results  of  the  survey  and  analysis  of  systems  are  discussed  in  two 
parts:  a  general  discussion  of  differences  in  common  features;  and  a 
more  detailed  discussion  of  specific  transaction  features,  organized  accord¬ 
ing  to  Table  4. 

General  Results 

The  systems  examined  during  this  task  seem  to  belong  roughly  to  two 
classes,  designated  "Class  I"  and  "Class  II"  for  convenience  of  expression. 

Table  5  repeats  the  systems  listed  earlier  in  Table  3,  this  time  broken  down 
into  the  two  classes.  These  classes  are  immediately  distinguishable  on  at  least 
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Table  5 


Systems  Examined  During  First  Phase  of  This 
Project,  Broken  Down  by  Classes 


CLASS  I 

CLASS  II 

TACFIRE 

DS4  Auto  Run  Book 

TOS2 

DLDED 

TCT 

PHOENIX  Auto  Run  Book 

IISS 

SDA 

BCS 

DAS  3 

MAGIS 

ISIS 

one  militarily  meaningful  criterion.  That  is,  Class  I  systems  will  provide 
data  processing  services  to  the  combat  and  combat  support  branches.  Class  II 
systems,  on  the  other  hand,  are  combat  service  support  systems.  The  two 
groups  differ  on  other  characteristics,  however,  that  are  more  important  from 
the  perspective  of  this  project.  These  differences  include  at  least  the 
following: 


a.  User/operator  interaction 

1.  In  Class  I  systems,  interaction  among  users  and  operators 
ranges  from  limited  in  IISS  to  moderate  in  MAGIS  to 
extensive  in  TACFIRE.  Much  of  this  interaction  is  job- 
related,  as  when  fire  requests  are  sent  from  the  Forward 
Observer  to  the  Artillery  Control  Console  Operator,  or 
when  an  intelligence  analyst  passes  processed  information 
from  one  terminal  to  another. 

2.  In  Class  II  systems,  there  is  very  little  interaction 
among  users  and  operators ,  and  even  that  is  confined 
largely  to  matters  of  system  operations,  as  when  the 
user  asks  for  a  magnetic  tape  to  be  mounted  or  for  a 
reinitialization  following  a  nonrecoverable  situation. 
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b.  Data  currency 

1.  In  Class  I  systems,  certain  classes  of  information  are 
highly  time-sensitive.  For  example,  information  about 
the  location  of  targets  may  be  valid  only  for  minutes; 
information  about  enemy  movements  may  be  valid  no  longer 
than  a  few  hours. 

2.  In  Class  II  systems,  few  information  items  are  so 
ephemeral.  For  example,  the  fact  of  a  lost  tank  is 
valid  until  that  tank  is  replaced,  no  matter  how  long 
it  takes.  The  same  is  true  of  personnel,  of  course; 
specialists  in  particular  may  be  difficult  to  replace. 

c.  Data  base  access/manipulation 

1.  In  Class  I  systems,  users  access  data  bases  directly 
and  interactively.  Thus,  an  update  entry  changes  a 
data  base  as  soon  as  validity  and  error  checking  are 
completed.  Also,  users  can  query  the  data  base 
directly. 

2.  In  Class  II  systems,  users  interact  directly  only  with 
an  interface  program.  That  is,  a  program  (or  even  a 
separate  small  computer  system)  is  used  interactively 
to  build  up  an  input  file  for  entry  into  another 
program,  perhaps  on  a  different  computer.  Similarly, 
queries  are  constructed  by  the  interface  program, 

then  passed  on  to  the  data  processing  system.  In  Class 
II  systems,  therefore,  users  interact  with  data  bases 
indirectly. 1 

The  differences  in  system  characteristics  that  yield  classifications  as 
described  above  have  implications  for  the  development  of  guidelines  and 
criteria.  For  example,  Class  I  systems  require  guidelines  for  the  design  of 
user-to-user  message,  and  of  procedures  for  transmitting  the  contents  of  a 
screen  display  or  data  file  from  one  user  terminal  to  another.  The  time- 
sensitivity  of  certain  information  types  probably  has  its  greatest  implications 
for  the  design  of  communication  links,  which  are  beyond  the  scope  of  this  pro¬ 
ject.  Nonetheless,  error  prevention  techniques  are  especially  important  with 
such  types  of  data,  and  guidelines  must  reflect  this  fact.  The  "distance" 
between  the  user  and  the  data  base  also  has  implications  for  error  prevention. 
Thus,  when  the  user  interacts  with  the  data  base  directly,  error  feedback  can 


1 /There  are  plans  to  make  future  generations  of  these  systems  more  directly 
interactive,  however. 


be  provided  immediately  for  any  detectable  error.  When  the  interaction  is  less 
direct,  on  the  other  hand,  only  certain  errors  can  be  detected  immediately  by 
the  interface  system  since  it  contains  little  or  none  of  the  data  base.  Con¬ 
sequently,  it  lacks  much  of  the  legal  value  information  required  for  error  and 
validity  checks.  The  result  is  that  error  feedback  to  the  user  is  delayed 
for  many  types  of  errors  until  after  the  larger  system  has  processed  the  input 
stream.  This  delayed  feedback  may  require  more  diagnostic  information  to  be 
as  effective  as  immediate  feedback  because  it  reaches  the  user  without  the 
contextual  cues  available  during  the  terminal  session  in  which  the  error 
occurred. 

Differences  in  common  features.  Battlefield  automated  systems  share  many 
common  features.  They  all  include  some  kind  of  keyboard,  for  example,  and  some 
kind  of  display  device.  Many  of  the  operations  they  perform  are  functionally 
similar,  such  as  calling  up  information  from  a  file,  and  transmitting  data 
from  the  display  to  the  CPU  for  processing.  Yet,  most  of  these  common  fea¬ 
tures  differ  from  one  system  to  another.  Figure  6  illustrates  some  of  these 
differences  in  general  design  features  among  five  systems  drawn  from  the 
larger  sample.  The  figure  shows  that  the  systems  differ  substantially  in  many 
respects,  as  for  example  in  the  command  types  they  employ  and  the  methods 
they  use  to  enter  commands. 

When  examined  in  closer  detail,  differences  among  systems  become  even  more 
apparent.  Figure  7  shows  nine  different  types  of  transactions  and  the  methods 
used  to  perform  them  on  the  five  systems.  Notice  in  the  figure  that  no  trans¬ 
action  is  performed  the  same  way  on  any  system,  even  if  only  the  Army  systems 
are  considered  (i.e. ,  TACFIRE,  TCS,  and  IISS.  Even  when  systems  appear  to 
use  the  same  method  for  the  same  or  similar  transaction,  these  similarities 
disappear  under  closer  inspection.  For  example,  Figure  7  shows  that  both 
TACFIRE  and  TCS  use  a  fixed  function  key  to  display  the  first  part  (or  page) 
of  the  next  block  (or  message)  to  be  worked  on.  They  even  use  the  same  generic 
terms — but  the  labels  are  spelled  differently.  Figure  8  shows  the  same  pattern 
of  differences  in  additional  transaction  types. 

The  use  of  symbols  also  is  inconsistent  from  one  system  to  the  next. 

Figure  9  shows  how  nine  different  non-alphabet ic  symbols  are  used  in  the  five 
systems  drawn  from  the  larger  sample.  Only  two  of  these  symbols  are  used  in 
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Figure  6.  Differences  among  general  design  features  of  selected  battlefield 
automated  systems. 
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Figure  7.  Differences  in  execution  of  selected  transaction  types  in  battle¬ 
field  automated  systems. 
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Figure  8.  Differences  in  execution  of  additional  transaction  types  in  battle¬ 
field  automated  systems. 
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Figure  9.  Differences  in  non-alphabetic  symbols  used  in  battlefield  automated 
systems. 
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all  five,  or  even  in  the  three  Army  systems.  And,  even  in  those  Army  systems, 
the  symbols  are  not  used  consistently. 

Figure  10  shows  examples  of  the  use  of  codes  to  express  Boolean/relational/ 
logical  operations.  Although  they  are  not  provided  in  all  systems  (TACFIRE 
and  the  DS4  Automated  Run  Book,  are  examples) ,  these  operations  typically  are 
used  to  define  subsets  of  information.  In  reviewing  the  status  of  units  follow¬ 
ing  a  battle,  for  example,  one  might  wish  to  obtain  the  unit  IDs  for  "all 
companies  tlr>t  suffered  casualties  greater  than  20%  of  authorized  strength." 
Erroneous  use  of  Boolean/relational/logical  operators  can  produce  misleading 
results  or  undesired  information.  For  instance,  entering  "<  20% "  instead  of 
">  20%"  could  generate  an  output  exactly  opposite  to  that  desired  in  the  above 
example.  As  another  example,  misusing  Boolean/relational/logical  operators  has 
led  to  line  printers  being  tied  up  for  excessive  periods  of  time  because  a 
user/operator  did  not  define  properly  an  appropriately  small  subset  of  infor¬ 
mation  to  be  printed  out  from  a  data  base. 
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Figure  10.  Symbols  used  for  Boolean/relational/logical  operators  in  battle¬ 
field  automated  systems. 
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User/operator  terminal  devices  provide  another  example  of  differences 
among  battlefield  automated  systems.  The  center  of  Figure  11  shows  a  repre¬ 
sentation  of  a  standard  office  typewriter  keyboard.  Obstensibly,  many  systems 
employ  the  same  keyboard.  As  Figure  11  shows,  however,  different  systems  use 
different  configurations  of  keys  for  non -alphanumeric  characters. 


Figure  11.  The  standard  office  keyboard  configuration  and  variations  found 
in  selected  battlefield  automated  systems. 

Even  within  a  given  system,  differences  i.i  keyboard  configuration  are  often 
found  between  different  terminals.  Figure  12,  for  example  shows  the  configura¬ 
tions  of  the  keyboards  on  two  TACFIRE  terminals,  the  Digital  Message  Device 
(DMD)  and  the  Artillery  Control  Console  (ACC).  Notice  that  on  the  DMD,  the 
alphanumeric  keys  are  arranged  in  alphabetical  order,  with  non-alphabetic  keys 
on  the  bottom  row.  By  contrast,  the  ACC  has  a  modified  QWERTY  (or  office  type¬ 
writer)  keyboard.  Additionally,  the  numeric  keys  on  the  DMD  are  arranged  in 
the  standard  desk  calculator  format;  meanwhile,  the  numeric  keys  on  the  ACC 
are  arranged  in  the  format  of  a  telephone  keyset. 
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Figure  12.  Two  keyboard  configurations  used  in  TACfIRE. 


System  differences  by  no  means  are  confined  to  hardware  configurations. 

For  example,  Figure  6  shows  that  TACFIRE,  TCS,  and  IISS  all  include  menus  in 
their  command  types.  This  apparent  similarity  disappears  when  the  menus 
themselves  are  inspected  (Figure  13) .  The  figure  shows  that  differences  in 
menu  display  configurations  are  as  great  as  those  in  hardware  configurations. 
Indeed,  methods  for  selecting  menu  options  also  differ:  in  TACFIRE,  the  cursor 
is  moved  to  the  space  to  the  right  of  the  desired  option  and  a  selection  char¬ 
acter  is  inserted;  in  IISS,  the  user  touches  the  desired  option  with  a  light 
pen;  and  in  TCS,  the  user  enters  the  line  number  of  the  selection. 

The  implications  of  differences  among  systems  such  as  those  described 
above  will  be  discussed  later  in  this  report.  The  next  section  discusses 
particular  transaction  features  in  more  detail. 

1 .  Control  Methods 

1 . 1  Command  Language.  Command  languages  are  not  generally  used  in  battle 
field  automated  systems.  TACFIRE  and  TCT,  for  example,  do  not  provide  user/ 
operator  access  to  a  command  language  at  all.  Evidently,  no  decision  has  been 


TACFIRE  PREFORMATTED  MESSAGE  INCLUDING  EDIT.  PRINT,  AND  DELETE  MENU 


CLASSIFICATION 

FOR  TRAINING  ONLY  f 

GIM  MENU 

ALL  OATA  BASES: 

ANALYSIS: 

INPUT:  I 

GIM  LANGUAGE 

EUNITS 

IUNITS 

UUNITS 

UTUGEO 

AUITF 

IAIRF 

UAIRF 

repdrtw 

ARFLDF  ACTF 

ARFLDF 

ACTF 

BOT 

PERSNF  PPTG1 

PERSNF 

PPTGT 

MISCELLANEOUS: 

RIIF  RWY 

RIIF 

RWY 

NEXT  ACTIVITY 

INSTF 

INSTF 

1  EXTRACT  PILOT  DATA 

ANALYSIS.  INPUT  ANO  MISCELLANEOUS  COLUMNS 

FOR  USE 

WITH  TACCB  DATABASE  ONLY! 

iV  GIM  MENU 


DATA  ENTRY  FORMAT  "''NU  SELECTION 

1.  SYSTEM  INITIALIZ' .ION 

2.  CHANNEL  INITIALISATION 

3.  LOCAL  USER  INITIALIZATION 

4.  LINK  INITIALIZATION 

5.  SUBSCRIBER  INITIALIZATION 

6.  COMMUNICATION  ERROR  THRESHOLDS 

7.  INITIALIZATION  AUTHORIZATION 

8.  ANTI-JAM  MATRIX 

SELECT  (  ) 


TCS  SYSTEM  INITIALIZATION  MENU 


Figure  13.  Menu  display  configurations  in  three  Army  battlefield  automated 
systems. 


made  for  DLDED  in  regard  to  a  command  language.  Users/operators  of  the  DS4 
Automated  Run  Book  will  have  access  to  the  DAS  3  GCOS  command  language  ,  but 
apparently  it  will  be  used  only  for  special  operations,  and  then  infrequently. 
The  IISS  offers  the  richest  command  language  capability  of  all  the  systems 
encountered  in  this  project.  Depending  on  the  type  of  control  transaction  to 
be  performed,  IISS  users  may  choose  among: 

a.  The  Honeywell  TSS  Command/Monitor  language. 

b.  The  Honeywell  H-6000  Batch  Job  Control  Language. 

c.  Software  switches  (i.e.,  codes)  which  perform  as  a 
kind  of  command  language. 

d.  The  GIM-II  language. 

Of  these,  GIM-II  is  undoubtedly  the  most  important.  A  user/operator  who 
possesses  a  detailed  knowledge  of  this  language  can  use  it  to  perform  virtually 
any  IISS  function  quickly  and  efficiently. 

Command  languages  are  extremely  powerful  and  highly  flexible  methods  for 
controlling  the  sequences  of  computer  processes.  Their  syntax  and  structure 
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are  defined  precisely;  they  are  designed  to  be  as  concise  as  possible,  with 
heavy  use  of  brief  abbreviations  and  codes.  These  attributes  eliminate  the 
ambiguity,  redundancy,  and  lack  of  precision  characteristic 

Employed  by  a  skilled  and  experienced  user/operator ,  command  languages  permit 
very  rapid  and  efficient  interaction  with  the  computer.  This  becomes  especially 
true  when  the  command  language  is  combined  with  a  "command  macro"  capability. 

Command  macros  basically  are  computer  programs  written  in  command  language 
instead  of  more  conventional  programming  languages  such  as  COBOL  or  FORTRAN. 

They  are  useful  whenever  a  user/operator  frequently  enters  the  same  sequence  of 
command  verbs  and  parameters  to  perform  a  routine  function.  If  the  system 
includes  a  command  macro  capability,  the  user/operator  writes  the  commands 
as  a  command  macro,  assigns  it  a  name,  and  saves  it  in  a  personal  file.  Then, 
when  the  user/operator  needs  to  perform  the  function,  merely  entering  the  name 
of  the  command  macro  causes  the  function  to  be  executed. 

The  same  attributes  of  command  languages  and  macros  that  make  them  such 
powerful  tools  for  skilled,  experienced  users/operators,  however,  tend  to  make 
them  very  difficult  for  unskilled,  inexperienced,  unsophisticated  personnel. 
Their  syntax  and  structure,  so  different  from  those  of  normal  language,  appear 
unnatural  and  even  unhuman  to  the  unskilled.  The  properties  of  verbs, 
connectors,  qualifiers,  and  literals  that  give  command  languages  their  power 
and  flexibility  also  introduce  subtle  traps  for  the  unwary.  Abbreviations  and 
codes  mystify  the  unitiated,  forcing  heavy  reliance  on  off-line  sources  with 
attendant  costs  in  time  and  frustration. 

Additionally,  the  precision  and  concise  structure  of  command  languages 
make  many  of  them  extremely  inflexible  in  terms  of  entry  requirements.  Words, 
abbreviations,  and  codes  must  be  spelled  correctly.  The  format  of  each  command 
statement  must  be  followed  rigidly,  with  parameters  arranged  in  their  proper 
sequence  and  appropriate  delimiters  placed  in  their  proper  positions.  Given 
these  factors,  unsophisticated  users  often  become  confused  and  commit  any  of 
a  number  of  errors,  including: 

a.  Simple  typographical  errors. 

b.  Leaving  out  required  parameters. 

c.  Entering  extraneous  parameters. 

d.  Arranging  parameters  in  the  wrong  order. 
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e.  Entering  incompatible  parameters. 

At  best,  such  errors  result  in  error  messages  and  the  necessity  to  re-enter 
command  statements,  with  consequent  delays  in  data  processing  and  user/ operator 
frustration.  At  worst,  erroneous  data  could  be  entered  into  data  bases;  data 
processing  functions  could  be  executed  improperly,  unnecessarily,  or  prematurely; 
or  data  files  could  be  destroyed. 

1.2  Menus.  Menus  are  used  in  one  form  or  another  in  all  the  battlefield 
automated  systems  encountered  in  this  project.  TACFIEE  makes  only  limited  use 
of  them,  and  does  not  use  them  well  from  the  user's/operator's  point  of  view. 
Recall  that  in  Figure  13  menu  options  were  embedded  in  a  preformatted  message. 
Another  type  of  menu  is  the  format  directory  message,  listing  the  message  for¬ 
mat  types  in  each  message  category.  In  both  cases,  menu  options  are  listed 
horizontally.  This  imposes  a  burden  on  the  user/operator  because  scanning  is 
more  difficult  when  trying  to  locate  the  desired  option  quickly.  A  more 
serious  problem  occurs  in  actually  designating  an  option.  To  do  so,  the 
user/operator  positons  the  cursor  to  the  element  field  of  the  data  element. 
Depending  on  the  particular  message  and  option,  the  user/operator  then  enters 
an  "X,"  an  "A"  a  "Y , "  and  "S,''  or  some  other  character.  Some  of  these  data 
elements  permit  more  than  one  legal  entry  (such  as  "A"  for  "all"  and  other 
characters  for  other  options) .  For  most,  however,  only  one  character  is  legal. 
The  legal  character  differs  from  one  data  element  field  to  another:  one  element 
field  requires  an  "X,"  another  requires  an  "A,"  and  so  on.  The  system  provides 
no  on-line  assistance  indicating  which  letter  is  required  for  a  given  element 
field.  Thus,  the  user/ operator  must  know  which  letter  will  satisfy  the  require¬ 
ment  of  each  menu  data  element.  This  necessity  imposes  an  excessive  memory 
burden  on  the  user/operator  and  creates  a  highly  error-prone  situation  for  no 
defensible  purpose. 

The  TCT  uses  menus  extensively.  The  message  format  type  is  selected  from 
a  format  menu  (Figure  14)  which  is  accessed  by  pressing  the  FRMT  DIR  (format 
directory)  fixed  function  key.  The  message  format  is  displayed  on  the  upper 
portion  of  the  display  screen.  As  the  cursor  moves  from  data  field  to  data 
field,  a  prompt  is  provided  for  some  fields  and  a  menu  of  appropriate  responses 
for  other  fields  appears  in  the  prompt  area  of  the  screen.  Even  non-numeric 
data  are  entered  by  inputting  numeric  codes. 


30 


TCT 

FORMAT  MENU 

01 

SITREP 

02 

SPOT 

03 

UT0 

04 

FREE 

I  SELECT  J 

Figure  14. 

The  TCT  format  menu 

For  example,  suppose  the  user/operator  selects  the  SITREP  message  format  by 
entering  a  "l"  (the  leading  zero  need  not  be  entered)  and  then  pressing  the 
"ENTER"  key.  Figure  15  shows  the  SITREP  format  after  the  first  data  field  has 
been  filled  (see  1.5  Prompts /HELPS) . 
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Figure  15.  The  TCT  SITREP  message  format  with  menu  for  second  data  field  at 
bottom  of  screen. 
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The  message  format  itself  appears  in  the  upper  portion  of  the  screen,  called 
the  Message  Display  Area.  Below  that,  user/operator  selections  will  appear 
in  the  "SELECT  <  >"  area.  Near  the  bottom  of  the  frame  is  the  prompt  Display 
Area.  When  the  list  of  legal  values  for  a  data  field  is  short,  they  will  be 
displayed  in  a  menu  in  this  area,  as  illustrated  in  the  figure.  The  user  enters 
the  appropriate  number  to  indicate  the  desired  option,  and  presses  the  "ENTER" 
key.  The  selected  information  item  (e.g. ,  "UNCLASSIFIED")  appears  in  the  mes¬ 
sage  format  immediately.  The  use  of  menus  in  this  manner  relieves  the  user/ 
operator  of  the  necessity  to  remember  the  list  of  legal  values,  or  to  refer 
to  off-line  sources.  This  practice  should  thus  help  to  reduce  errors  and 
increase  processing  efficiency.  One  minor  problem,  however,  was  observed  in 
TCT  menu  usage.  At  some  points  in  the  initialization  process,  the  TCT  display 
menu  options  for  communication  channel  characteristics  that  are  illegal,  given 
the  characteristics  selected  in  previous  menus.  For  example,  if  "NRZ"  is  the 
selected  modulation,  then  only  1200,  2400,  4800,  and  9600  are  valid  data  rates. 
However,  the  system  presents  all  11  of  the  available  data  rates,  thereby  forc¬ 
ing  the  user/operator  to  remember,  for  each  successive  menu,  which  options 
remain  valid,  given  earlier  menu  selections.  This  requirement  imposes  an 
unnecessary  memory  burden  on  the  user/operator. 

In  contrast  to  TCT,  the  IISS  does  not  use  menus  extensively.  Indeed, 
there  are  only  two  pure  menus  in  the  system,  a  master  menu  (Figure  16 
GIM-II  language  menu  (Figure  17) .  Both  the  MASTER  MENU  and  the  GIM  MENU  indi¬ 
cate  available  options  by  listing  brief  terms  or  abbreviations  for  those  op¬ 
tions.  The  user/operator  must  remember  the  meaning  of  the  terse  option  descrip¬ 
tions.  This  poses  unnecessary  memory  loading  on  the  users/operators  of  the 
system.  Failing  to  recall  the  meaning  of  the  terse  prompts  may  result  in  the 
user/operator  selecting  an  inappropriate  item  from  the  menus,  or  in  the  necess¬ 
ity  for  looking  up  the  meanings  of  prompts  in  reference  documentation.  Addi¬ 
tionally,  to  select  options  from  either  the  MASTER  MENU  or  the  GIM-II  MENU, 
the  IISS  user  places  the  light  pen  tip  over  any  portion  of  the  term  or  phase 
denoting  the  desired  option.  The  terminal  "beeps"  to  indicate  that  the  light 
pen  is  positioned  over  a  valid  entry.  The  user  must  then  press  the  SEND  key 
to  enter  the  selection  into  the  IISS  system.  If  the  user  is  selecting  the  GIM-II 
MENU  from  the  MASTER  MENU,  the  light  pen  is  used  for  two  selections  in  a  row; 
otherwise  the  user  enters  commands  and  data  using  the  SU  1652  terminal  key¬ 
board.  This  requires  the  user  to  look  away  from  the  display,  locate  the  light 
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Figure  16.  The  IISS  master  menu.  Redrawn  from  IISS  User's  Manual,  page  3-5. 

pen,  position  it  accurately,  note  the  terminal  feedback  indicating  appropriate 
positioning,  and  then  press  the  SEND  key  to  enter  the  selection.  This  requires 
the  use  of  two  different  command  modes,  each  of  which  requires  the  use  of 
different  kinesthetic  and  hand-eye  cues.  Subsequent  interactions  require  that 
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Figure  17.  GIM-II  Menu  on  the  IISS.  Redrawn  from  IISS  User's  Manual,  p.  3-36. 
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the  user  locate  the  light  pen  clip,  place  the  light  pen  there,  and  then  prepare 
to  enter  data  or  commands  from  the  keyboard.  Thus,  the  user  is  required  to  com¬ 
plete  many  actions  which  are  not  necessary  for  efficient  selection  of  MASTER 
MENU  and  GIM-II  MENU  options.  This  may  slow  users  down  during  high-stress 
operations. 

Menus  provide  the  major  method  for  selecting  DS4  processing  cycles,  and 
for  invoking  the  data  entry  and  error  correction  functions.  In  general,  the 
Run  Book  menus  are  very  well  designed  from  the  user's  point  of  view,  with 
only  minor  deficiencies.  One  such  deficiency  is  the  method  for  presenting 
error  messages.  When  a  user  selects  an  illegal  option  (for  example,  enters  "5" 
from  the  master  menu  illustrated  in  Figure  18),  the  system  responds  with: 

->  Only  entries  0  through  4,  99  and  HELP  are  valid  selections  <- 

and  then  repeats  its  invitation  to: 

->  Please  enter  the  line  number  which  describes  what  you  want  to  do  <- 

^  **********direct  support  unit  standard  supply  system******^ 

Hello!  I  am  DS4  and  I  am  ready  to  help  you  do  your  supply 

function.  Please  review  the  following  list  of  things  I  can 

help  you  do  and  select  the  job  you  wish  me  to  help  you 

with: 

0  I  need  help! 

1  We  want  to  do  Production  Processing. 

2  We  want  to  do  a  Data  Reduction  Function. 

3  We  need  to  execute  a  software  utility. 

4  We  want  to  do  a  list  of  all  cycles. 

99  It  is  time  to  terminate  this  session. 


L->  PLEASE  ENTER  THE  LINE  NUMBER  WHICH  DESCRIBES  WHAT  § 

YOU  WANT  TO  DO  <-  I 

Figure  18.  Master  Menu  for  the  DS4  Automated  Run  Book. 

These  messages  are  excellent  in  that  they  provide  information  about  legal 
entries  (see  3.  Data  Entry  and  Handling).  The  deficiency  appears  only  if  the 
user  commits  several  errors  on  the  same  menu.  Each  time  an  error  occurs,  the 
error  message  and  correction  message  are  painted  on  the  screen  below  the  pre- 
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ceding  messages.  When  the  bottom  line  of  the  screen  has  been  used,  scrolling 
begins — and  part  or  all  of  the  menu  might  be  lost  off  the  top  of  the  screen. 
This  will  happen,  of  course,  at  a  time  when  the  user  still  needs  to  be  able 
to  read  the  menu  explanation  and  options.  Another  deficiency  is  the  space 
between  option  numbers  and  the  text  description  of  the  option  in  some  menus 
(for  example,  the  master  menu;  also,  see  6.  Glossaries).  This  space  is  wide 
enough  to  require  closer  attention  than  should  be  necessary  to  associate  an 
option  number  with  its  corresponding  description.  The  width  of  this  space 
could  contribute  to  errors  in  entering  menu  selections  (possibly  exacerbating 
the  problem  described  above) . 

A  related  deficiency  is  the  arrangement  of  single-digit  option  numbers 
vertically  above  the  tens  position  of  double-digit  option  numbers  (for  example, 
see  Figure  19).  This  arrangement  will  not  be  a  serious  source  of  errors 
although  it  may  confuse  some  individuals  at  least  momentarily.  Even  so,  it 
detracts  from  operator  "comfort"  with  the  system,  because  it  violates  a  popu¬ 
lation  stereotype  (i.e.,  most  people  in  Western  cultures  have  learned  to 
expect  that  numbers  will  be  listed  with  their  units  positions  lined  up  verti¬ 
cally)  . 


MONTHLY  REPORTS-PROCESSES* 
0  I  need  HELP  (FUNCTIONAL  GUIDANCE) 


1 

We 

need 

to 

do 

a 

MONTHLY  CONSOLIDATION 

2  (AP) 

We 

need 

to 

do 

a 

P.EPCRTABLF  ITEMS  LISTING  (AESRS) 

3  (AS) 

We 

need 

to 

do 

a 

AUTHORIZED  STOCKAGE  LIST 

4  (BU) 

We 

need 

to 

do 

a 

BOTTOM  UP  RECONCILIATION 

5  (CS) 

We 

need 

to 

do 

a 

REQUEST  FDR  CATALOG  OATA 

6  (DA) 

We 

need 

to 

do 

a 

DMD  ANALYSIS  (OHA  EXTRACT, 

DMD  HIST,  DST,  ASL  UPOATE 

7  (DH) 

We 

need 

to 

do 

a 

DEMAND  HISTORY  UPOATE 

8  (FS) 

We 

need 

to 

do 

a 

FINANCIAL  STOCKAGE  LIST 

9  (MK) 

We 

need 

to 

do 

a 

PERIODIC  MRO  STATISTICS 

1D(0U) 

We 

need 

to 

do 

a 

OUF  UPDATE  PROCESS 

ll(SP) 

We 

need 

to 

do 

a 

SUPPLY  PERFORMANCE  REPORT 

1 2(TR) 

We 

need 

to 

do 

a 

PERIODIC  TRANSACTION  REGISTER 

13(TS) 

We 

need 

to 

do 

a 

PERIODIC  INPUT  TRNASACTION 

STATISTICS 

T  4 ( CU ) 

We 

need 

to 

do 

a 

CATALOG  UPDATE  PROCESS 

15(XP) 

We 

need 

to 

do 

a 

EXCESS  PROCESS 

99 

It 

is  time 

to 

TERMINATE  THIS  SESSION 

->  Please  enter  the  line  number  which  describes  what  you  want  to  do<- 


V _ J 


Figure  19.  Example  of  misaligned  option  numbers  in  a  DS4  Automated  Run  Book 
menu. 


Whereas  command  languages  and  command  macros  provide  powerful  and  flexible 
tools  to  the  skilled,  experienced  user/operator,  properly  designed  menus  pro¬ 
vide  almost  as  much  power  to  the  unskilled,  inexperienced  user/operator.  They 
break  a  task  down  into  its  components,  and  then  guide  the  individual  through 
a  series  of  simple,  discrete  decisions.  In  this  manner,  expecially  when  com¬ 
bined  with  adequate  prompts  and  HELPS  (discussed  below) ,  menus  greatly  relieve 
the  heavy  memory  burden  imposed  by  command  languages  and  command  macros. 

And  yet,  as  users/operators  begin  to  acquire  experience  and  confidence  with 
the  system,  the  advantages  of  menus  begin  to  fade.  Even  when  not  yet  ready  to 
use  command  language  or  other  methods,  they  find  menus  boring  and  confining. 

Many  begin  to  feel  that  menus  slow  them  down.  Possibly,  too,  menus  contribute 
to  a  feeling  that  the  computer,  rather  than  the  user/operator,  controls  the 
interaction. 

This  is  not  to  say  that  menus  are  a  panacea.  Indeed,  anecdotal  evidence 
from  systems  not  included  in  this  analysis  suggest  that  as  users/operators 
gain  experience  and  confidence  with  their  system,  some  of  the  advantages  of 
menus  start  to  diminish.  Even  when  not  yet  sufficiently  experienced  to  use 
command  languages  or  other  control  methods  effectively,  users/operators  often 
begin  to  find  menus  boring  and  confining.  Many  start  to  feel  that  menu 
sequences  slow  them  down,  delaying  performance  of  the  functions  the  computers 
are  supposed  to  support.  Possibly,  too,  the  rigid  "lock-step"  procedure 
imposed  by  menu  sequences  contributes  to  a  feeling  that  the  computing  machinery, 
rather  than  the  user/operator,  controls  the  interaction. 

As  an  example,  consider  a  situation  in  which  the  user/operator  needs  to 
enter  daily  cycle  transaction  data  from  the  DAS  3  user  terminal  for  process¬ 
ing  by  one  of  the  DS4  supply  cycles.  The  session  begins  with  the  master  menu 
illustrated  above,  in  Figure  18.  In  the  conventional  menu  sequence,  the 
individual  enters  a  "2"  to  indicate  a  data  reduction  task.  The  computer 
responds  with  a  menu  of  all  the  available  data  reduction  processes  (Figure  20) . 
Since  the  user/operator  wants  to  enter  daily  cycle  data,  the  appropriate  entry 
is  "2."  The  system  next  presents  the  various  daily  cycle  options  (Figure  21). 
The  individual  enters  a  "1"  to  indicate  the  need  to  input  new  data.  The  com¬ 
puter  responds  with  its  final  menu  in  the  sequence,  a  list  of  the  various 
methods  available  for  entering  new  data  (Figure  22).  The  user/operator  enters 


36 


a  "1"  to  indicate  that  input  will  be  provided  from  the  user  terminal.  The 
system  then  goes  into  a  prompting  mode  at  this  point,  to  assist  the  individual 
to  complete  the  data  entry  task.  This  procedure  clearly  benefits  people  who 
are  not  well  acquainted  with  the  computer  or  its  operational  sequences.  But 
as  the  user/operator  learns  the  menu  selection  sequence  through  repetition, 
he  or  she  reaches  the  point  of  knowing  at  the  outset  that  the  required  string 
of  selections  is  "2,"  "2,"  "1,"  and  "1".  It  is  at  this  point  that  frustra¬ 
tion  may  begin  to  emerge.  BETA  Test  Bed  operators,  for  example,  are  reported 
to  experience  just  this  kind  of  frustration  with  menu  sequences  in  that  system. 


========DATA  REDUCTION  CYCLE  SELECTI 0N===== 


I  need  HELP 

We  want  to  do  data  reduction 
We  want  to  do  data  reduction 
We  want  to  do  data  reduction 
We  want  to  do  data  reduction 
process . 

We  want  to  do  data  reduction 
INSERT  process. 

We  want  to  do  data  reduction 
EXTRACT  process. 

We  want  to  do  data  reduction 
process . 

We  want  to  do  data  reduction 
process . 

It  is  time  to  TERMINATE  this 


for  PLL  Update  process, 
for  DAILY  CYCLE  process, 
for  CATALOG  UPDATE  process, 
for  PARAMETER  UPDATE 

for  UNIT  DEMAND  HISTORY 

for  UNIT  DEMAND  HISTORY 

for  MASS  CANCELLATION 

for  REQUEST  FOR  INVENTORY 

session. 


— ->  Please  enter  the  line  number  which  describes  what  you 
want  to  do  < — 


Figure  20.  The  menu  showing  the  data  reduction  processes  available  on  the 
Automated  Run  Book. 


- -  V 

DAILY  CYCLE  DATA  ENTRY/CORRECTION  SELECTION 

0  I  need  help! 

1  We  need  to  input  new  data. 

2  We  want  to  correct  data. 

3  We  need  a  combination  of  1  and  2  above. 

99  It  is  time  to  terminate  this  session. 


>  Please  enter  the  line  number  which  describes  what 
you  want  to  doc- 


v. 


J 


Figure  21.  The  menu  used  to  indicate  whether  the  user  wishes  to  enter  new 
data  or  correct  erroneous  data  for  the  daily  cycle  process. 


PRODUCTION  DATA  ENTRY  MEDIA  SELECTION 
0  I  need  help! 

1  We  need  to  enter  data  from  this  terminal. 

2  We  need  to  input  data  from  card  (CDROO). 

3  We  need  to  input  data  from  tape  (M  900) 

4  We  need  a  combination  of  1  and  2  above. 

5  We  need  a  combination  of  1  and  3  above. 

6  We  need  a  combination  of  2  and  3  above. 

7  We  need  a  combination  of  1 ,  2  and  3  above. 
99  It  is  time  to  terminate  this  session 


->  Please  enter  the  line  number  which  describes  what 
you  want  to  do<- 


Figure  22.  The  menu  used  to  indicate  which  device  (s)  will  be  used  for  data 
entry  during  a  data  reduction  process. 


1 . 3  Function  keys.  Function  keys  are  a  prominent  design  feature  in 
nearly  all  of  the  battlefield  automated  systems  encountered  during  this  project. 
They  are,  however,  configured  in  different  ways  in  the  various  systems,  and 
they  are  used  for  widely  differing  purposes. 
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Both  fixed  and  variable  function  keys  form  important  components  of  the 
overall  IISS  command  mechanism;  the  fixed  function  keys  are  contained  in  three 
groups,  while  the  variable  function  keys  are  contained  in  two  separate  groups 
(Figure  23) .  The  two  separate  types  of  functions  are  distinguished  not  only 
by  position,  but  also  by  general  command  function. 

The  IISS  fixed  function  keys  control  highly  terminal -oriented  functions, 
such  as  those  required  for  text  editing  (on  the  screen  of  the  SU  1652) ,  those 
indicating  that  the  user  is  ready  to  send  information  from  tha  SU  1652  to  the 
main  IISS  processor,  and  those  involved  in  selecting  between  the  SU  1652  dual 
display  screens.  These  n  ctions  depend  heavily  on  the  processing  capability 
of  the  SU  1652 .  The  fixed  function  keys  are  always  "active ; "  that  is ,  their 
associated  functions  will  be  enabled  any  time  the  key  is  pressed. 

The  IISS  variable  function  keys  control  IISS  activities  which  have  more  to 
do  with  the  processor  (AN/GYQ-21 (V) )  than  the  terminal.  The  SU  1652  processor 
must,  of  course,  evaluate  the  key  pressed  and  generate  the  correct  series  of 
codes  to  be  sent  to  the  processor.  In  general,  however,  its  role  is  merely 
one  of  formatting  and  communication.  The  terminal  itself  takes  no  action  that 
is  immediately  evident  to  the  user.  The  variable  function  keys  are  "variable" 
only  in  that  they  are  not  always  active.  The  actual  function  of  any  particular 
key  is  constant,  assuming  that  it  is  active.  The  function  of  the  key  will  not 
change  during  IISS  operations.  It  should  be  noted,  however,  that — unlike  the 
fixed  function  keys — the  action  of  the  variable  function  keys  can  be  changed 
via  terminal  and  system  reprogramming.  The  functions  of  the  variable  function 
keys  are  not  labeled  on  the  keys  themselves,  but  rather  on  the  transparent 
underlays  placed  besdie  each  "strip"  of  keys.  There  are  lights  under  each  key 
label  cell.  When  the  function  is  active,  the  light  under  the  corresponding 
key  label  cell  is  lit. 

The  extensive  use  of  function  keys  in  IISS  has  several  benefits: 

a.  It  provides  a  source  of  constant  "prompts"  for  IISS  users, 
since  the  key  labels  are  imprinted  on  the  keys  or  written 
in  the  key  label  cells.  This  reduces  the  memory  burden  on 
users/operators . 

b.  It  assures  that  terminology  associated  with  particular 
functions  will  be  consistent.  Since  the  labels  are  consistent, 
programmers  maintaining  or  updating  the  system  cannot  mistakenly 
introduce  terminological  inconsistency. 
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Figure  23.  SU  1652  Keyboard  and  Controls. 


c.  The  way  in  which  the  variable  function  keys  are  implemented  in 
IISS  is  particularly  useful  in  reducing  user  memory  burden. 

Some  implementations  merely  label  VFKs  with  numbers,  requiring 
either  that: 

1.  The  user  remember  what  functions  are  associated  with  a 
specific  variable  function  key  number. 

2 .  A  menu  be  presented  on  the  screen  indicating  what  VFK 
is  to  be  pressed  to  perform  a  particular  function.  Not 
only  does  this  method  burden  system  main  and  peripheral 
memory  resources,  but  it  also  requires  that  the  user 
split  attention  between  keyboard  and  screen . 

The  IISS  implementation  has  neither  disadvantage.  There  are,  however,  ways 
in  which  the  employment  of  function  keys  is  sub-optimal  in  IISS,  particularly 
for  novice  users /operators . 

a.  IISS  displays  do  not  indicate  to  the  user/operator  what 
function  keys  (fixed  or  variable)  are  typically  used  in 
conjunction  with  the  operations  to  which  the  displays  refer. 

b.  Where  the  list  of  function  keys  and  the  explanation  of  their 
effects  are  too  lengthy  to  place  on  system  displays,  no  function 
key  HELP  is  available  to  present  to  the  user  the  list  of  the 
function  keys  active  at  the  current  point  in  IISS  operations. 

c.  Labels  on  the  VFKs  are  not  very  informative — there  is  cer¬ 
tainly  room  in  the  VFK  labels  areas  for  more  text.  More 
informative  labels  would  not  degrade  the  performance  of 
experienced  users/operators,  but  would  make  the  system 
easier  to  use  by  less  sophisticated  individuals. 

Function  keys  are  also  employed  extensively  in  the  TCT.  Two  sets  of 
variable  (programmable)  function  keys  are  located  along  the  right  side  and 
bottom  of  the  display  screen.  The  functions  of  these  keys  vary  with  the  mode 
of  operation  and  are  identified  by  labels  which  appear  on  the  display  screen. 
The  TCT  also  makes  extensive  use  of  fixed  function  keys  on  both  the  display 
panel  and  the  keyboard  panel. 

In  the  main,  both  variable  and  fixed  function  keys  are  used  effectively 
on  the  TCT.  Two  features  of  their  use,  however,  are  potentially  troublesome. 
First,  the  TCT  must  be  initialized  each  time  the  system  is  moved,  and  each 
time  task  organization  changes  the  configuration  of  communications  equipment 
and  computer  terminals.  The  initialization  procedure  involves  two  "pages" 
of  display  formats,  into  which  the  user/ operator  enters  initialization  data. 
There  appears  to  be  no  conceptual  distinction  between  pages  1  and  2;  they  are 
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always  completed  in  the  same  sequence,  and  both  pages  must  be  completed  to 
initialize  the  TCT.  Available  documentation  describes  no  processing  options 
after  page  1  is  completed;  the  user/operator  must  proceed  to  page  2.  However, 
to  obtain  page  2  displays,  the  user/operator  must  press  the  DATA  INIT  and  CHNG 
FCTN  keys.  The  user/operator  must  remember,  first  that  function  keys  are 
required  to  obtain  page  2  displays,  and  second  the  proper  sequence  of  key 
presses.  While  not  great,  the  memory  and  administrative  burden  imposed  upor 
the  user/operator  by  this  requirement  is  unnecessary.  Second,  at  various 
points  in  TCT  operations,  the  system  presents  a  "mode  selection  alert"  to  the 
user/operator.  This  alert  indicates  that  the  user/ operator  must  select  one  of 
the  system's  available  modes  of  operation.  The  mode  selection  procedure  is 
not  uniform  for  all  modes,  however. 

a.  To  select  the  TEXT  EDIT  or  DATA  ENTRY  modes,  the  user/ 
operator  must  press  and  hold  down  the  interlock  key 
(INTLK)  while  simultaneously  pressing  the  appropriate 
mode  selection  key. 

b.  To  select  the  CYCLE  MSG  or  REPL  modes,  the  user/operator 
merely  presses  the  appropriate  mode  selection  key,  the 
INTLK  key  need  not  be  used. 

The  system  does  not  provide  any  prompts  as  to  when  the  interlock  key  is  required 
or  not  required.  Therefore,  the  user/operator  must  remember  which  modes  require 
the  interlock  key,  and  which  do  not.  This  requirement  imposes  an  unnecessary 
memory  burden. 

The  majority  of  TACFIRE  function  keys  are  contained  on  the  ACC  SPA  (Figure 
24) ;  function  keys  on  the  VFMED  and  DMD  are  more  limited  in  number,  but  those 
available  perform  functions  similar  to  their  counterparts  on  the  ACC. 

The  function  keys  generally  are  straightforward  in  their  labels  and  opera¬ 
tions.  One  exception  to  this  general  rule  is  the  DELETE  key.  Pressing  this 
key  on  the  SPA  clears  the  RD  and  displays  the  next  message.  The  message  is 
automatically  cleared  and  removed  from  the  receive  queue  when  the  DELETE  switch 
is  pressed.  If  a  segment  of  a  message  is  being  displayed,  only  that  segment 
of  the  message  is  deleted.  However,  if  the  segment  that  is  deleted  happens  to 
be  the  first  segment  of  the  message,  the  entire  message  is  deleted,  i.e., 
removed  from  the  RD  and  also  removed  from  the  message  queue.  There  is  no  pro¬ 
tection  feature  for  priority  messages.  The  operator  could  inadvertently  delete 
an  important  message  by  accidentally  pressing  the  delete  switch  or  by  not 
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Figure  24.  Configuration  of  the  Artillery  tontrol  Console 


recognizing  that  deleting  the  first  message  segment  will  delete  the  entire 
message.  Unintentional  deletion  of  the  first  segment  will  delete  the  entire 
segmented  message.  Thus,  important  messages  could  be  lost  inadvertently. 

Although  the  DAS  3  user  terminal  is  equipped  with  a  variety  of  function 
keys,  only  the  cursor  control  keys  are  used  in  the  DS4  Automated  Run  Book. 

In  this  connection,  two  deficiencies  are  apparent  in  the  data  reduction  func¬ 
tion.  Both  are  potentially  troublesome.  First,  if  user/operator  enters  an 
erroneous  character  and  then  detects  the  error  before  leaving  the  data  field, 
it  is  possible  to  correct  the  error.  The  first  step  is  to  move  the  cursor 
back  to  the  error  character,  either  by  pressing  the  key  or  the  "< — "  cursor 
control  key  (but  not  by  pressing  the  "BACKSPACE"  key,  it  acts  like  the  "TAB" 
key).  The  next  step  is  to  press  the  key  for  the  proper  character,  thereby 
overprinting  the  error  character  on  the  screen .  However,  what  the  user/operator 
sees  on  the  screen  may  or  may  not  reflect  what  will  go  into  the  computer  when  the 
data  entry  is  completed  and  the  "RETURN"  key  is  pressed  to  enter  the  data.  For 
example,  suppose  the  user/operator  intends  to  type  "YEH,"  inadvertently  types 
"YEF,"  moves  the  cursor  back  to  the  "F,"  and  types  "H."  On  the  screen,  the 
individual  will  now  see  "YEH,"  the  proper  character  string.  However,  the 
character  string  that  will  be  entered  into  the  computer  depends  on  how  the 
cursor  was  moved  backward.  That  is,  if  the  user/operator  pressed  the: 

a.  key,  the  "H"  will  replace  the  "F"  on  the  screen  and  in 
the  input  character  string,  so  that  the  computer  will 
receive  "YEH." 

b.  "< — "  key,  the  "H"  will  replace  the  "F"  on  the  screen  but 
not  in  the  input  character  string,  so  that  the  computer  will 
receive  "YEFH." 

Clearly,  using  the  "< — "  when  attempting  immediate  correction  of  typographical 
errors  will  result  in  processing  errors  as  well;  time  will  be  wasted,  users/ 
operators  will  be  frustrated,  and  errors  may  be  introduced  into  the  DS4  data 
base.  Unfortunately,  this  may  well  become  a  frequent  problem  in  the  field 
because  the  "< — "  naturally  lends  itself  to  moving  the  cursor  backward.  This 
is  especially  true  for  personnel  who  have  had  experience  on  other  systems. 

Second,  in  the  error  correction  mode,  correcting  an  error  card 
begins  with  the  system  painting  an  80-column  image  of  the  card  near  the 
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top  of  the  screen.  The  user/operator  can  compare  this  image  with  the  error  card 
itself,  on  which  have  been  indicated  the  data  fields  containing  errors  and  the 
corrections  to  be  made.  If  the  Document  Identifier  Code  (DIC)  is  wrong,  it  is 
corrected  in  the  horizontally  formatted  card  image.  Then,  to  edit  the  remainder 
of  the  card,  the  user/operator  presses  the  "RETURN"  key.  The  system  breaks  the 
horizontal  card  image  into  separate  data  items,  with  one  item  per  line.  Each 
line  shows  the  card  column (s)  in  which  the  data  item  appears,  a  field  identifier 
that  also  serves  as  a  prompt,  and  the  data  currently  in  that  field.  The  column 
numbers  and  field  identifiers  are  protected;  after  the  entire  display  is  painted, 
the  cursor  returns  automatically  to  the  first  character  position  of  the  data 
field  on  the  second  line  (the  first  item — the  DIC — was  corrected,  if  necessary, 
on  the  horizontally-formatted  card  image) .  The  user/operator  may  either  change 
the  existing  entry  by  typing  in  the  correct  data,  or  accept  the  existing 
entry  by  skipping  the  field.  To  advance  to  the  next  data  field,  the  indivi¬ 
dual  may  press  any  of  four  keys:  "RETURN,"  "TAB,"  "BACKSPACE,"  or  "  ". 

The  editing  operation  is  not  completed  until  the  user/operator  either  has 
entered  correct  data  in  the  data  field  on  the  last  line,  or  else  has  skipped 
past  that  field.  Thus,  if  only  the  second  field  must  be  corrected  in  a  trans¬ 
action  of,  say,  twelve  fields,  then  the  user/operator  must  press  "RETURN"  (or 
"BACKSPACE,"  or  "TAB,"  or  "  ")  ten  times  after  correcting  the  error  before 

he  or  she  can  proceed  to  the  next  transaction.  While  the  necessity  to  do  so 
probably  will  not  increase  error  rates,  it  does  consume  time  and  contribute 
to  boredom,  frustration,  and  antipathy  toward  the  sytem. 

1.4  Hybrid  methods.  Hybrid  methods  are  combinations  of  methods  used  to 
control  the  sequence  of  operations  in  a  computer.  Thus,  function  keys  might  be 
used  to  indicate  menu  selections,  or  menus  might  be  used  to  list  command  verbs. 
The  most  unique  hybrid  method  observed  in  both  the  initial  survey  and  more 
detailed  analyses  is  the  format  selection  matrix  on  the  TACFIRE  ACC  SPA.  This 
matrix,  illustrated  on  the  left  side  of  Figure  24,  contains  64  cells  in  an 
8x8  arrangement.  A  paper  overlay,  listing  format  designator  codes,  is  fitted 
over  the  matrix.  In  use,  when  a  message  format  is  required  for  entering  data, 
the  format  must  be  called  up  from  storage.  To  select  a  message  format,  the 
user/operator  first  locates  the  proper  code  on  the  matrix,  then  pushes  one 
button  below  the  column  in  which  the  code  is  located,  and  finally,  pushes 


another  button  to  the  right  of  the  row  in  which  the  code  is  located.  The 
intersection  containing  the  desired  message  format  code  first  must  be  located. 
Then,  the  user/operator  must  track  both  horizontally  and  vertically  to  locate 
the  buttons  required  to  identify  the  proper  intersection.  The  procedure 
requires  careful  eye-hand  coordination  to  avoid  errors. 

Another  problem  with  the  format  selection  matrix  arises  from  the  fact 
that  matrices  at  division  and  battalion  have  47  format  name  codes  in  common. 

Of  these,  19  are  placed  in  the  same  location  on  the  matrices  at  both  division 
and  battalion  (the  codes  enclosed  in  boxes  in  Figure  25) .  The  remaining  28 
common  codes  are  at  different  locations  on  the  two  matrices  (the  codes  in 
circles  in  Figure  25) .  Users/operators  who  transfer  from  battalion  to 
division  or  vice-versa  will  confuse  locations  on  their  "old"  matrix  with  those 
on  their  "new"  matrix.  This  confusion,  which  will  be  greatest  for  the  user/ 
operators  with  the  greatest  experience,  will  greatly  increase  the  probability 
of  errors . 

The  wide  variety  of  command  methods  available  in  IISS  virtually  assures 
that  some  hybrid  methods  will  be  employed.  The  most  significant  and  pervasive 
combinations  employed  in  IISS  are:  (a)  combination  of  form  filling,  menus, 
and  fixed  function  keys;  (b)  of  light  pen  and  function  keys;  and  (c)  the 
variable  function  keys. 

Combination  of  form  filling,  menu,  and  fixed  function  key  methods.  Using 
the  MMI  forms  to  control  IISS  operations  requires  that  all  three  of  these 
methods  be  employed: 

a.  Form  filling  is  the  core  command  method,  since  codes  must  be 
entered  into  the  MMI  forms  to  define  subsequent  processing 
operations . 

b.  Menu  selection  is  used  to  provide  the  list  of  "switch"  commands 
which  may  be  used  to  complete  the  forms.  This  aspect  of  the 
command  is  advantageous  since  it  obviates  remembering  the 
"switch"  command  language. 

c.  Fixed  function  keys  are  used  to  position  the  screen  cursor 
in  the  appropriate  field  for  switch  entry. 

Combination  of  light  pen  menu  selection  and  fixed  function  key  methods. 
When  the  MASTER  MENU  and  the  GIM  MENU  are  used  in  IISS,  the  user  first  uses 
the  SU  1652  light  pen  to  select  the  desired  option.  The  user  must  then  press 
the  SEND  key  to  transmit  the  selection  to  the  main  IISS  processor. 
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DIVISION 


BATTALION 


Figure  25.  TACFIRE  SPA  Message  Format  Selection  Matrices  for  Division  and 
Battalion  Computers. 


Use  of  variable  function  keys  throughout  IISS  operations.  The  highly 
flexible  variable  function  key  configuration  of  the  SU  1652  allows  it  to  be 
used  in  IISS  when  a  variety  of  other  command  methods  are  being  employed.  In 
many  such  circumstances,  the  variable  function  keys  form  a  constantly  avail¬ 
able  set  of  "global  system  options." 

The  TCT  and  the  DS4  Automated  Run  Book  do  not  incorporate  hybrid  methods 
such  as  those  described  above,  although,  as  noted  earlier,  the  TCT  uses  menus 
to  help  the  user/operator  to  choose  the  appropriate  data  item  for  many  message 
fields. 

1.5  Prompts/HELPS .  Battlefield  automated  systems  utilize  a  wide  variety 
of  prompts,  although  HELPS  are  more  plentiful  in  some  systems  than  in  others. 
Both  of  these  features  are  exemplified  in  the  paragraphs  that  follow. 

The  TCT  provides  extensive  prompts.  For  example,  recall  the  SITREP  mes¬ 
sage  in  Figure  15,  under  "1.2  Menus."  As  noted  there,  the  system  provides 
menus  for  those  data  fields  for  which  the  list  of  legal  values  is  short.  When 
the  list  of  legal  values  is  longer,  the  system  provides  an  instructive  prompt. 
Figure  26  provides  an  example.  Notice  in  the  figure  that,  instead  of  a  menu 


of  possible  values  for  the  first  data  field,  the  Prompt  Display  Area  of  the 
screen  contains  an  instructive  statement  of  what  the  user/operator  should  do, 
and  information  about  the  range  of  legal  values  for  the  field. 
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AOA  SYSTEM  X 
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Lt  rO-NODE  JJ 

ENTER  THE  NUMBER  (00-99)  THAT 
IDENTIFIES  THE  TERMINAL  TO  RECEIVE 
THE  MESSAGE. 


Figure  26.  The  SITREP  message  format  with  prompt  for  first  data  field  at 
bottom  of  screen. 


Although  prompts  in  the  TCT  generally  are  well-designed,  problems  were 
observed  in  a  few  cases.  For  example,  after  the  user/operator  has  initialized 
the  TCT,  the  message  "INITIALIZATION  IS  COMPLETE"  appears  in  the  operator  alert 
area  of  the  display  screen.  At  this  point,  the  user/operator  must  select  one 
of  the  system's  four  modes  of  operation  in  order  to  continue  processing.  How¬ 
ever,  the  system  provides  no  indication  that  the  user/operator  must  take  some 
action.  The  user/operator  must  remember  that  an  action  is  necessary  after 
the  "INITIALIZATION  IS  COMPLETE"  message  appears.  In  this  situation,  an  inex¬ 
perienced  user/operator,  or  one  under  stress,  may  simply  wait  for  the  system 
to  provide  instruction  for  the  next  transaction  (especially  in  the  TCT;  be¬ 
cause  it  has  generally  good  prompts,  user/operator  personnel  are  "trained"  to 
expect  prompts).  Even  if  he  or  she  remembers  that  a  mode  must  be  selected,  the 
user/operator  must  still  recall  the  four  modes  of  operation  and  their  associated 
designators.  Also,  during  TCT  initialization,  the  user/operator  specifies  the 
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characteristics  of  communications  channels,  selecting  from  menus.  For  example, 
to  select  the  device,  one  of  the  following  is  entered: 

1.  KY-57 

2 .  MODEM 

3.  CAU 

4.  LOCAL  RADIO 

5 .  REMOTE  RADIO 

6.  2-WIRE 

7.  4-WIRE 

8 .  CURRENT  LOOP 

Some  of  the  terminology  used  in  the  menu  (e.g.,  KY-57,  MODEM,  CURRENT  LOOP)  may 
be  excessively  technical  for  users/operators,  forcing  them  to  remember  unfamiliar 
designations. 

Consistency  in  the  construction  of  prompts  is  also  a  minor  problem  in  the 
TCT.  For  example,  in  the  SITREP  and  CRAP  message  formats,  the  prompt  for 
identifying  the  receiving  terminal  r.ode  is:  "ENTER  THE  NUMBER  (00-99)  THAT 
IDENTIFIES  THE  TERMINAL  TO  RECEIVE  THIS  MESSAGE."  The  SPOT  and  FREE  message 
formats  also  require  the  user/operator  to  identify  the  receiving  terminal 
node.  However,  in  these  two  messages,  the  prompt  is:  "ENTER  THE  NUMBER  IDENT¬ 
IFYING  TERMINAL  TO  RECEIVE  THIS  MESSAGE."  The  difference  in  wording  between  the 
two  functionally  identical  prompts  provides  an  unnecessary  opportunity  for 
confusion.  The  failure  to  indicate  the  range  of  legal  values  in  the  second 
prompt  adds  another  opportunity  for  confusion  in  the  SPOT  and  FREE  messages. 

Prompts  are  also  plentiful  in  TACFIRE.  That  is,  the  8x8  format  selec¬ 
tion  matrix  and  the  individual  format  directory  menus  provide  prompts  regarding 
message  format  identifiers  (e.g.,  FM;RFAF).  Also,  each  message  format  con¬ 
tains  data  element  names  to  prompt  the  user/operator  to  enter  data  in  the  ele¬ 
ment  fields.  Many  of  these  prompts  are  highly  meaningful  (e.g.,  "COORD"  for 
coordinates  and  "FUZE"  for  fuses)  and  aid  the  user/operator  to  decide  what 
data  are  required  in  the  element  field.  However,  TACFIRE  is  inconsistant  in 
regard  to  prompts,  in  two  ways.  First,  many  prompts  cannot  easily  be  associated 
with  a  data  type  (e.g.,  "D"  does  not  associate  with  subscriber  index  n limber ) . 
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Second,  the  same  prompt  is  often  associated  with  more  than  one  data  type  (e.g., 
"D"  refers  to  subscriber  index  number  in  the  SYS;  ADDR  message,  and  to  command 
post  location  and  closing  time  in  the  AFU;SR  message).  These  issues  are  dis¬ 
cussed  further  under  "6.  Glossaries." 

Prompts  are  used  extensively  in  the  Automated  Run  Book.  Menu  items,  of 
course,  provide  explicit  prompts  for  selecting  functions.  Questions  provide 
prompts  to  elicit  parameters  required  to  generate  ECL  card  images.  Prompts 
are  also  provided  in  both  data  entry  and  error  correction.  In  general,  prompts 
appear  to  have  been  well-designed,  providing  clear  and  specific  information 
about  what  is  needed  from  the  user. 

A  certain  amount  of  prompting  is  always  presented  in  the  IISS,  in  the 
form  of  the  FFK  legends  and  the  illuminated  labels  associated  with  the  VFKs. 
Beyond  these,  the  availability  of  prompts  in  the  system  depends  on  the  particu¬ 
lar  operating  mode.  For  example,  the  MMI  mode  uses  input  forms  and  menus. 

This  mode  includes  a  variety  of  prompt  types,  including  data  field  labels  on 
interactive  forms,  "switch  lists"  providing  information  about  legal  software 
switches  for  a  given  form,  and  the  menu  contents  themselves  providing  lists  of 
legal  values.  In  other  modes,  prompts  tend  to  be  terse  and  uninformative,  as 
in  the  COPY  option  of  the  TELETYPE  mode.  The  sole  prompt  for  this  option  is 
"COP>. "  The  lack  of  information  in  prompts  is  particularly  unfortunate  in 
view  of  the  system's  HELPS,  discussed  below. 

HELPS  are  software  routines  which  allow  the  user/operator  to  break  out 
of  the  normal  procedure  for  a  transaction,  obtain  assistance  regarding 
definitions  of  terms  or  values  of  legal  entries,  and  then  return  to  the  point 
at  which  the  normal  procedure  was  interrupted.  These  HELPS,  of  course,  are 
of  greatest  assistance  to  the  inexperienced  user/operator ,  because  they  pro¬ 
vide  immediate  aid  online,  at  the  point  of  difficulty,  without  the  need  to  con¬ 
sult  off-line  sources.  But  HELPS  are  necessary  for  experienced  users/operators 
as  well,  when  they  work  with  an  unfamiliar  portion  of  the  system,  or  arter  A 
period  of  time  away  from  the  system.  This  is  particularly  true  when  the  sys¬ 
tem  is  complex. 

IISS  is  an  extremely  complex  system.  As  such,  there  are  a  wide  variety 
of  functions  and  input  codes  which  have  to  be  used  by  IISS  intelligence  analysts. 
And  yet,  IISS  provides  only  a  single  HELP  display  (Figure  27) ,  which  provides 
a  brief  description  of  the  major  MASTER  MENU  and  TELETYPE  capabilities  of  the 
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system.  No  other  HELP  information  is  available  on-line  (except  for  function 
key  labels) .  Explanatory  information  is  available  in  hard  copy  but  is  spread 
across  several  documents.  Even  the  single  HELP  display  illustrated  in  Figure  27 
provides  rather  terse  information.  Furthermore,  in  some  cases,  the  contents 
of  the  HELP  display  are  inconsistent  with  available  IISS  processing  options: 


a.  The  HELP  display  includes  a  reference  to  a  HALT  option. 
This  capability  is  not  listed  on  the  MASTER  MENU,  nor  is 
it  discussed  as  one  of  the  TELETYPE  options. 


b.  The  HELP  display  contains  no  reference  to  the  SANITIZER 
option,  which  is  available  from  both  the  MASTER  MENU 
(the  SANITIZER  option)  and  the  TELETYPE  (the  MMU  >  CBL 
option) . 

c.  The  HELP  display  contains  no  reference  to  the  PLOT  option, 
which  is  also  available  in  both  MASTER  MENU  and  TELETYPE 
modes. 


d.  The  HELP  display  includes  a  reference  to  a  NOTE  option, 
which  is  not  presented  in  the  MASTER  MENU  nor  in  the 
TELETYPE  documentation  in  the  IISS  Users  Manual. 


The  user/operator  will  have  to  resolve  the  inconsistencies  between  the  HELP 
display  and  the  manifest  capabilities  of  IISS.  This  will  be  confusing,  and  may 
lead  to  hesitancy  on  the  part  of  users/operators  to  employ  required  capabilities. 
Without  a  well-conceived  HELP  capability,  the  complexity  of  the  system  imposes 
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Figure  27.  The  List  of  Function  Descriptions  Resulting  from  Selection  of  the 
HELP  Option  from  the  Master  Menu.  Redrawn  from  IISS  User's  Manual,  p.  3-8. 
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significant  memory  burdens  on  its  operators.  They  must  either  commit  all  of 
the  information  to  memory  or  refer  to  external  documents  if  their  recall  fails. 

No  HELPS  were  observed  in  the  TACFIEE  system.  The  lack  of  such  HELPS 
is  a  serious  deficiency.  The  system  has  over  200  messages  incorporating  over 
900  different  data  fields  (see  also  "6.  Glossaries").  With  no  on-line  assist¬ 
ance  to  define  data  field  codes  (many  of  which  cannot  be  .associated  meaning¬ 
fully  with  the  type  of  data  to  be  entered) ,  the  user/operator  must  refer  to 
off-line  sources  (running  to  10  volumes)  for  assistance  at  virtually  any  point 
of  difficulty. 

At  the  time  that  the  DS4  Automated  Run  Book  was  analyzed,  only  a  few  HELPS 
had  been  implemented.  These  few  were  quite  good,  containing  information  rele¬ 
vant  to  the  task,  and  written  in  clear  and  explicit  language.  Other  HELPS 
will  be  added  as  development  continues:  developers  should  be  encouraged  to 
show  as  much  concern  for  the  system's  prospective  functional  users/operators 
as  they  have  shown  thus  far. 

The  TCT  provides  HELPS  in  the  form  of  operator  and  system  alerts  displayed 
on  the  plasma  screen.  Operator  alerts  provide  direct  instructions  to  the  user/ 
operator  regarding  seme  sources  of  action.  System  alerts  are  more  cautionary, 
or  identify  courses  of  action  dependent  upon  other  system  indicators. 

2.  Display  Format 

Display  formats  are  a  particularly  important  aspect  of  the  user-computer 
software  interface.  The  arrangement  and  organization  of  display  formats  can 
present  information  in  logical,  natural  orders,  with  adequate  separation  among 
fields  to  facilitate  locating  particular  items,  and  thus  greatly  enhance  user/ 
operator  perf ormance .  Conversely,  they  can  present  information  as  a  disordered 
jumble,  with  data  items  densely  packed  and  inadequately  labeled,  and  thus 
actually  degrade  user/operator  performance.  In  general,  battlefield  automated 
system  developers  have  recognized  the  importance  of  good  display  design, 
although  a  number  of  problems  were  observed,  as  noted  below. 

2.1  Fixed  alphanumeric  displays,  on  the  uss,  the  dual  80  column  by  24 
line  screens  of  the  SU  1652  provide  a  great  deal  of  flexibility  in  creating 
alphanumeric  displays.  The  "screen  area"  organization  of  the  displays  does, 
however,  somewhat  constrain  the  available  display  space.  II5S  fixed  format 
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alphanumeric  displays  are  generally  well  organized  for  readability.  There 
are,  however,  two  exceptions  to  this  general  rule: 

a.  Individual  TACOB  fields  are  often  not  organized  for  maximum 
readability.  In  particular,  geographic  coordinates,  UTM 
coordinates,  dates,  and  times  should  be  broken  into  subfields 
for  display.  Geographic  coordinates  provide  one  example. 
Geographic  coordinates  are  displayed  by  IISS  primarily  to 
indicate  the  position  of  units  in  the  TACOB  order-of -battle 
files.  These  coordinates  are  provided  in  one  or  both  of  two 
forms: 

1.  Latitude/longitude  (GEO) ,  which  has  the  format: 

ddmmssAdddmmssA 

Lat  Lon 

where : 

d  =  degrees  (maximum  of  two  characters  for  latitude; 

maximum  of  three  characters  for  longitude) 
m  =  minutes 
s  =  seconds 

A  =  N  (North)  or  S  (South) 

Li3.  t 

A  =  E  (East)  or  W  (West) 

Lon 

An  example  of  a  GEO  display  is  354327N0972801E 

2.  Universal  Transverse  Mercator  (UTM),  which  has  the  format: 

nnAAAnnnnnnnn 

where : 

n  =  numeral 

A  =  alphabetic  character 

The  IISS  document  does  not  further  define  the  UTM  format. 

The  IISS  user/operator  is  sometimes  required  to  copy  geographic 
coordinates  information  from  one  place  to  another  (as,  for 
instance,  in  UTM/GEO  or  GEO/UTM  conversion).  The  user/operator 
must  break  the  geographic  coordinate  into  its  separate  sub¬ 
fields  (e.g. ,  dd-mm-ss)  mentally.  The  probability  of  misread¬ 
ing  the  closely  packed  characters  is  thus  relatively  high. 

b.  Where  display  space  is  not  at  a  premium,  both  the  labels  of 
TACOB  record  elements  and  the  contents  of  those  elements  should 
be  expanded  to  increase  meaningfulness.  A  fiei.)  currently 
labeled  RRDAT,  for  example,  might  be  translated  for  the 
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user/operator  to  read  READ.  RATE  DATE  or  READINESS  RATING 
DATE.  This  approach  will  be  particularly  useful  where: 

1.  Users/operators  have  not  had  time  to  gain  significant 
experience  in  the  use  of  IISS. 

2.  Functions  are  used  rarely  {e.g.,  IN  ANAL). 

TACFIRE  displays  are  severely  limited  in  regard  to  space.  Each  display 
on  the  ACC  and  VFMED  is  fixed  at  7  lines  and  72  columns.  As  a  result,  displays 
tend  to  be  densely  packed  with  information,  making  difficult  any  atcempt  to 
scan  a  message  to  find  a  selected  data  item  or  to  review  a  completed  message 
for  accuracy  and  completeness.  In  addition,  the  VFMED  is  a  "dumb"  terminal; 
it  contains  no  storage,  processing  capability,  or  message  buffer.  Thus,  after 
transmitting  a  request  to  the  computer  for  a  message,  or  after  transmitting 
a  completed  message,  the  display  screen  must  be  cleared  before  the  next  message 
arrives.  If  the  screen  is  not  cleared  before  the  new  message  arrives,  the  new 
message  simply  overprints  whatever  is  on  the  screen  at  that  moment.  The  VFMED 
user/operator  must  take  overt  action  to  clear  the  display  screen  before  an 

incoming  message  arrives.  In  a  busy  situation,  such  as  an  exercise  or  tactical 
operation,  the  user/operator  may  forget  to  perform  this  procedure.  An  arriving 
message,  overprinting  the  screen's  existing  contents,  may  be  uninterpretable. 
The  transaction  will  be  delayed  while  the  user/operator  requests  transmission 
of  a  new  "copy"  of  the  required  format.  Alternatively,  the  user/operator 
may  elect  to  attempt  reconstruction  of  the  "garbled"  message  by  typing  in  the 
overprinted  portions .  This  procedure  would  require  the  user/operator  to  type 
in  data  element  names — in  precisely  the  correct  character  positions — as  well 
as  the  data  that  he/she  normally  enters  in  element  fields .  This  is  a  time- 
consuming  and  highly  error-prone  procedure. 

An  even  more  serious  problem  concerns  the  arrangement  of  drta  fields  in 
TACFIRE  messages.  Data  fields  common  to  two  or  more  message  formats  often 
appear  in  different  places  from  one  field  to  the  next.  For  example,  the  codes 
"FRLT,"  "NFL,"  "FCL, "  and  "DSA"  appear  in  two  message  formats  used  to  input 
battlefield  geometry  data  (SPRT:GEOM  and  SPRTrBUIID).  The  codes  appear  on 
different  lines  in  the  two  formats,  in  different  orders  within  the  lines,  and 
in  different  column  groups.  Users/operators  must  exercise  care  in  switching 
from  one  message  format  to  the  other  not  to  confuse  the  sequence  of  codes. 

This  requirement  imposes  an  unnecessary  burden  on  the  user/operator  in  terms 
of  memory  load  and  attention  to  detail. 
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Output  reports  also  present  problems.  Some  output  reports  have  headings 
or  identifiers  (e.g.,  SYS;1201),  while  others  don't.  On  the  latter,  the  infor¬ 
mation  is  merely  printed  out,  and  the  user/operator  must  recognize  the  report 
by  its  content.  Also,  some  reports  have  the  same  identifier,  but  different 
contents.  For  example,  a  SYS; 1201  report  can  contain  a  list  of  all  message 
types  authorized,  a  list  of  subscribers,  a  list  of  legal  message  types  for 
input,  a  list  of  legal  message  types  for  auto  relay,  and  a  list  of  message 
addresses.  The  various  segments  just  described  can  also  be  printed  separately; 
each  such  segment  will  be  identified  as  SYS; 1201.  There  is  great  potential 
for  confusion  between  various  segmented  and  complete  reports  as  users/operators 
search  for  specific  items  of  information. 

All  displays  observed  in  the  DS4  Automated  Run  Book  fit  in  the  category  of 
fixed  alphanumeric  displays.  The  only  variable  elements  in  the  displays  are  the 
values  entered  into  data  fields;  the  fields  themselves  are  of  fixed  length. 

Fixed  alphanumeric  displays  are  appropriate  for  the  applications  implemented 
in  the  Automated  Run  Book.  They  are  generally  well-designed  to  facilitate  user 
interaction  with  the  computer.  No  deficiencies  were  observed  in  this  category 
(however,  see  2.4  Highlighting). 

The  TCT  uses  a  two-page  fixed  alphanumeric  display  for  system  initializa¬ 
tion,  and  four  preformatted  fixed  alphanumeric  displays  during  system  opera¬ 
tions.  The  TCT  message  formats  are  well  designed  in  that  they  are  not  cumber¬ 
some  either  in  size  or  density.  Data  fields  containing  multiple  pieces  of 
information  of  fixed  length  (e.g.,  TO,  FROM)  are  appropriately  sectioned  off 
to  guide  the  user/operator  in  data  entry.  For  other  alphanumeric  fields  of 
fixed  length  (e.g.,  TRANS-TIME),  the  prompts  are  such  that  size  and  data  entry 
type  (alpha  versus  numeric)  are  clearly  indicated  to  the  user/operator. 

2.2  Variable-length  alphanumeric  displays,  variable-length  alphanumeric 
displays  are  not  a  common  feature  in  battlefield  automated  systems.  The  DS4 
Automated  Run  Book  and  the  TCT  do  not  incorporate  any  displays  of  this  type , 
and  no  plans  are  known  to  implement  them.  TACFIRE  documentation  refers  to  seg¬ 
mented  messages,  but  these  appear  to  be  sequences  of  fixed  alphanumeric  messages 
strung  together.  In  IISS,  the  only  known  variable-length  alphanumeric  display 
is  the  "INDEX  LIST,"  which  lists  data  records  from  the  data  base  that  satisfy 
criteria  entered  previously  by  the  user/operator.  While  the  length  of  the 
INDEX  LIST  varies  with  the  number  of  data  records  satisfying  the  criteria, 
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the  display  in  other  respects  has  the  characteristics  of  a  fixed  alphanumeric 
display.  Thus,  the  analysis  of  systems  yields  no  important  results  in  this 
category . 

2.3  Graphics  displays.  Few  important  results  emerged  from  the  analysis 
in  regard  to  graphics  displays.  Though  most  systems  appear  to  have  at  least 
some  graphics  capability,  in  some  it  is  not  used  (for  example,  the  DS4  Auto¬ 
mated  Run  Book)  or  used  infrequently.  TACFIRE  provides  graphic  display  cap¬ 
ability  only  with  the  DIVARTY  computer.  The  major  problem  noted  in  connection 
with  this  device  is  that  it  presents  information  essentially  in  "free  space." 
That  is,  the  device  has  no  capability  to  use  map  overlays  or  underlays,  and  it 
does  not  display  identifying  terrain  features.  Thus,  graphic  symbols  appear 
on  the  display  without  contextual  information,  necessitating  frequent  refer¬ 
ences  to  a  separate  map.  Perhaps  as  a  consequence,  the  graphics  plotter  appar¬ 
ently  is  not  used  often. 

A  graphic  display  capability  is  incorporated  into  TCT.  However,  graphics 
were  not  considered  part  of  the  Phase  1  implementation  of  TCT  and  therefore, 
no  transaction  feature  analysis  was  possible . 

No  true  graphic  or  pseudo  graphics  (i.e.,  graphics  constructed  from 
characters)  are  available  at  the  SU  1652  terminal.  Geographically-oriented 
plots  are  available  using  the  PLOT  option,  but  this  option  is  not  currently 
implemented  for  IISS  analyst  users.  These  plots  must  be  performed  with  the 
assistance  of  highly  skilled  system  operators.  Plots  are  made  on  a  Calcomp 
flatbed  plotter.  The  review  team  did  not  have  an  opportunity  to  assess 
plotter  formats  or  symbology. 

2.4  High! iqhtinq.  Developers  of  battlefield  automated  systems  appear 
not  to  appreciate  the  value  of  highlighting.  Highlighting  is  the  use  of  color, 
brightness  changes,  underlining,  blinking,  or  other  distinctive  variations 
from  the  normal  appearance  of  the  display  screen.  It  is  used  to  draw  a  user's/ 
operator's  attention  to  a  particular  area  of  the  display  containing  especially 
important  information  such  as  alerts  or  error  messages,  or  to  help  the  indi¬ 
vidual  locate  important  words  or  phrases.  Used  in  these  ways— and  used  spar¬ 
ingly,  highlighting  can  be  an  effective  aid  to  enhanced  user/operator  perform¬ 
ance. 
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Only  one  highlighting  feature  was  observed  in  the  TCT.  As  shown  in  Figure 
15  and  again  in  Figure  26,  a  box  is  put  around  the  line  on  which  data  are  being 
entered  into  a  message  format.  This  box  would  be  more  effective  if  it  surrounded 
only  the  data  field  currently  being  entered;  nonetheless,  it  at  least  helps  the 
user/operatcr  locate  the  line  containing  that  field. 

The  only  instance  of  highlighting  in  TACFIRE  occurs  on  the  DMD,  where  the 
element  name  flashes  to  identify  the  data  element  currently  being  completed. 

The  ACC  and  VFMED  apparently  have  no  highlighting  capability  to  draw  the  user's/ 
operator's  attention  to  particularly  important  portions  of  the  display. 

Even  when  developers  have  greater  highlighting  capability,  either  they 
have  not  used  it  at  all,  or  they  have  not  used  it  as  effectively  as  they  might. 
For  example,  in  IISS,  the  SU  1652  has  a  number  of  features  which  could  be  em¬ 
ployed  to  highlight  important  information,  including  brightness  control,  reverse 
display,  and  blinking.  IISS  does  not,  however,  use  any  of  these  forms  of  high¬ 
lighting. 

The  DAS  3  user  terminal  has  extensive  highlighting  capability:  blinking, 
inverse  video,  two  levels  of  brightness,  boxing  (using  graphics  features) , 
and  upper  and  lower  case.  The  DS4  Automated  Run  Book's  developers  have  utilized 
some  of  these  capabilities  effectively,  although  not  consistently.  For  example, 
consider  Figure  28,  which  contains  two  examples  of  inconsistent  highlighting. 

Here  Is  a  recap  of  what  I  think 
you  have  asked  for  to  this  point: 


1  We  want  to  do  Production  Processing. 

2  We  want  to  do  a  WEEKLY  report-process. 

1  We  need  to  do  a  WEEKLY  CONSOLIDATION 

★ 

Does  the  recap  indicate  we  are  about  to  do  the  proper 
report-process? 

Please  enter  YES  or  NO 
Y 

good,  we  can  now  proceed 


Figure  28.  A  sample  of  Automated  Run  Book  output  illustrating  two  examples 
of  highlighting  used  inconsistently. 
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First,  notice  that  sentences  in  the  display  begin  with  a  capital  letter,  except 
for  the  last  sentence,  in  which  "good"  begins  with  a  lower  case  letter.  Second, 
upper  case  letters  are  used  to  highlight  important  words  in  the  display,  such 
as  "WEEKLY  CONSOLIDATION,"  "YES,"  and  "NO."  But  "Production  Processing," 
surely  of  equal  importance,  is  capitalized  in  the  first  letters  only. 

Similarly,  in  the  data  reduction  function,  prompts  are  displayed  with 
lower  brightness  than  data  entries.  However,  the  same  highlighting  procedure 
does  not  appear  to  be  used  in  the  production  processing  function  when  questions 
are  used  to  prompt  the  user  for  ECL  parameters . 

Such  inconsistencies  (also  see  6.  Glossaries)  are  not  likely  to  be 
serious  sources  of  error,  nor  are  they  likely  to  cause  delays  in  data  process¬ 
ing  operations.  However,  even  minor  inconsistencies  can  introduce  a  jarring 
note  into  the  user/computer  relationship,  adversely  affecting  the  user's 
"image"  of  the  system.  That  is,  they  can  detract  from  the  user's  view  of  the 
computer  as  a  well-designed,  properly-functioning,  reliable  tool,  thereby 
affecting  the  user's  acceptance  of  the  system. 

3.  Data  Entry  Assistance 

3.1  Information  on  Legal  Entries.  The  battlefield  automated  systems  that 
were  studied  varied  widely  in  the  extent  of  legal  entries  information  they 
provide  on-line  at  the  terminal.  All  of  the  systems  provide  some  information 
on  the  format  of  information  to  be  entered.  IISS,  for  example,  indicates 
the  maximum  length  of  input  fields  by  displaying  underlines  (Figure  29)  in  its 
fill-in-the-blanks  data  entry  forms .  TACFIEE  uses  dots  for  the  same  purpose 
(Figure  29) .  TACFIRE  also  uses  virgules  (slashes)  and  commas  to  indicate 
subfields  within  the  data  entry  fields  (IISS  also  uses  the  virgule  technique, 
although  less  consistently) .  The  DS4  Automated  Run  Book  uses  underlines  to 
define  field  lengths  in  its  "production  process"  input  and  edit  routines; 
copies  of  screen  formats  were  not  available  for  inclusion  in  this  report. 

TCT  provides  some  input  format  information  when  the  data  to  be  entered 
is  not  categorical  (e.g.,  the  string  to  be  entered  is  an  integer  between  0  and 
180) .  Legal  values  information  about  formats  is  less  necessary  in  this  system 
than  in  others  because  of  its  use  of  input  menus.  DLDED  is  not  yet  sufficiently 
developed  to  permit  comment  upon  its  handling  of  legal  entries  formats. 
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IN  ANAL  dissemination  header  form,  showing  underlines  used  to  define  maximum 
field  length.  Redrawn  from  IISS  User's  Manual,  p.  3-20. 


. >  P . • >  SB . . / ././ •*/ >■•)£•••• j SG  t . . t . . « DT  z . / . .  ( I D  z . . , . j  A  z . » 

MET ;CFL;Q: . ;P0SI : . ;DTI: . ./. . , ;HGT : . . . ; 

LINA:../.../...,../.../...,../.,./ . A../...,.,/.../...* 

LINB:. . /.../ . /.../ . 

LINC: . ./.../ . . J 


Sample  TACFIRE  formatted  message,  showing  dots  used  to  define  maximum  field 
length. 


Figure  29.  IISS  and  TACFIRE  formats  indicating  maximum  field  lengths. 


There  is  much  less  consistency  in  the  extent  to  which  these  systems  pro¬ 
vide  the  user/operator  with  information  about  the  permissible  content  of  data 
entries.  All  used  some  variant  of  the  "fill-in-the-blanks"  form  of  informa¬ 
tion  entry,  but  the  human  factors  design  quality  of  the  implementations  is 
quite  variable.  The  best  of  the  lot  appears  to  be  TCT.  its  message  forms  are 
superficially  similar  to  those  of  TACFIRE  (see  Figures  29  and  30) ,  but  the 
technique  for  getting  information  into  the  message  "blanks"  is  completely 
different.  In  TACFIRE,  the  user/operator  must  enter  the  data  without  any  form 


:  ***  i  iwsy*?*: 
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TO-NODE :  HSG:SITREP  SCTY: .  PREC: . 

TRANS-TIME: .  GRID-ZONE:... 

TO:  .  EPF-TIME: . 

FROM:  .  MISSION: . 

MAIN  CP/PAD: . / .  TAC  CP/PAC: . / . 

COORD  PT: . - . - . - . . . 

FLT : . - . - . - . . 


ENEMV  ACTIONS/INTENSITY: . 

STATUS : 

DIESEL  AVAIL: . . .1  MOGAS  AVAIL .%  COMMO:  RADS:.... 

EQUIP  CREWS  AMMO  EQUIP  CREWS  AMMO 

ITEM:  AVAIL  AVAIL  AVAIL  ITEM:  AVAIL  AVAIL  AVAIL 

ATKHEL  . S  ADA  SYSTEM  . I 

UH1-M56  X  l 

CH47  1  j 

TOW  *  X 

DRAGON  *  j 

M60A1  . %  . . .  '  '* 

M60A2  *  X 

APC  %  X 

REMARKS: . 

. . *EOT* 

v _ / 


Figure  30.  Sample  TCT  Message  Format.  Reproduced  from  Tactical  Computer 
Terminal  User  Manual  for  Phase  1  of  European  Implementation  Plan  (Preliminary 
Draft).  Glendale,  California:  Librascope  Division  of  Singer,  1  August  1980. 
NOTE:  dots  appear  only  in  manuals;  they  are  not  displayed  on  tbs  terminal 
screen . 


of  prompting.  If  the  individual  forgets  the  legal  Values  for  a  certain  data 
entry  item,  a  hard  copy  reference  manual  must  be  consulted.  This  design  fea¬ 
ture  imposes  a  significant  memory  burden.  TCT,  on  the  other  hand,  presents 
the  user/operator  with  an  input  menu  (recall  the  bottom  of  Figure  15) ,  which 
provides  the  legal  values  for  all  of  the  possible  entries  in  the  data  field 
into  which  data  are  currently  being  entered.  This  data  entry  feature  has 
the  collateral  benefit  of  reducing  the  number  of  keystrokes  required  for  data 
entry,  since  the  user/operator  is  selecting  a  numbered  item  from  a  menu  rather 
than  entering  a  lengthy  string  of  characters. 

Data  entry  in  IISS  can  be  accomplished  in  two  different  ways.  Entering 
data  into  the  order  of  battle  data  bases  via  the  MMI  (man-machine  interface) 
mode  is  accomplished  by  filling  in  blanks  in  a  data  entry  form.  No  informa¬ 
tion  on  the  contents  of  legal  entries  is  provided.  In  GIMS  language  mode, 
the  user/operator  does  not  even  have  data  field  labels  to  cue  data  entry;  both 
"field"  or  "variable"  labels  and  data  entry  codes  and/or  formats  must  be 
recalled  from  memory. 
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Data  entry  in  the  Automated  Run  Book  of  the  DS4  is  also  accomplished 
by  filling  in  the  blanks  in  a  data  entry  "form"  printed  at  the  user  terminal. 
Essentially  no  information  on  the  legal  contents  of  these  fields  is  provided. 

All  of  the  systems  examined  provide  legal  entries  information  in  hard 
copy  reference  manuals;  none  provides  pointers  from  specific  data  entry  dis¬ 
plays  to  sections  or  individual  pages  of  code  books  or  other  reference  docu¬ 
ments  . 

All  in  all,  the  TCT  approach  of  providing  legal  values  in  menus  appears 
to  be  the  most  appropriate  for  U.S.  Army  battlefield  automated  systems.  All 
legal  values  are  provided  for  the  user /operator,  and,  for  those  data  fields 
where  a  fairly  small  set  of  categories  are  available,  there  is  no  need  to 
provide  information  on  legal  values  formats.  This  technique  should  be  partic¬ 
ularly  valuable  for  inexperienced  personnel,  who  may  not  be  as  comfortable  with 
the  entire  spectrum  of  permissible  input  values  as  their  more  experienced 
counterparts . 

There  are  two  potential  problems  with  the  use  of  menus  for  providing 
legal  values  information  in  the  form  of  input  menus.  The  first  of  these  con¬ 
cerns  the  handling  of  data  fields  where  the  range  of  possible  responses  is 
finite  but  large.  Since  the  display  space  for  menus  is  limited,  the  designer 
may  be  forced  to  provide  multi-page  menus  to  provide  all  legal  entries.  This 
may  force  the  user/operator  to  page  through  the  menu  lists  until  the  desired 
data  entry  is  located.  This  process  is  time-consuming,  and  may  frustrate 
experienced  operators/users.  The  second  problem  involves  the  entry  of  infor¬ 
mation  by  very  experienced  users/operators.  Even  reasonably  well  designed 
menu  data  entry  systems  may  become  unsatisfactory  to  personnel  who  are  able 
to  anticipate  their  desired  data  entries  several  steps  ahead  (see  1.2  Menus) . 
This  problem  can  be  particularly  acute  when  many  of  the  entries  are  optional 
menu  systems  cannot  anticipate  which  entries  must  be  filled  in,  and  which  may 
be  left  blank.  A  third  potential  problem  with  menu-oriented  data  entry  systems 
involves  data  entry  items  with  permissible  responses  which  are  not  categoriz- 
able,  such  as  dates,  ranges,  etc.  The  appropriate  strategy  here  may  be  to 
be  replacing  the  menu  with  a  relatively  detailed  set  of  information  about  the 
format  of  the  response  required.  This  is  the  approach  taken  in  TCT,  and  in 
the  production  processing  portion  of  the  DS4  Automated  Run  Book. 
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3.2  Unburdening  of  Input.  All  of  the  battlefield  automated  systems  in 
the  sample  use  at  least  one  method  to  reduce  the  number  of  keystrokes :  coding 
and/or  abbreviation  of  data  entry  values.  All  also  have  some  method  for  pro- 
pogating  constant  information  (such  as  the  current  date)  so  that  it  need  not 
be  repeatedly  re-entered  by  users/operators .  Other  methods  for  unburdening 

of  input  are  tied  to  the  interaction  id.iosyncracies  of  the  particular  systems. 
IISS,  for  example,  features  a  number  of  provisions  designed  to  reduce  the  amount 
of  information  which  its  users  must  enter  to  build  and  maintain  order  of 
battle  files.  Included  are: 

a.  Automatic  generation  of  geographic  coordinates. 

b.  Automatic  generation  of  dates. 

c.  Automatic  update  of  position  tracks. 

The  DS4  Automated  Run  Book  prints  out  the  existing  information  for  transactions 
to  be  edited,  relieving  users/operators  of  the  necessity  to  re-enter  correct 
information. 

There  was  little  evidence  of  some  of  the  more  sophisticated  methods  for 
reducing  the  input  burden  on  users/operators,  such  as  probabilistic  genera¬ 
tion  of  candidate  data  entries  and  user-directed  specification  of  data  entry 
contractions.  There  is  considerable  evidence,  however,  that  some  relatively 
straightforward  techniques  for  reducing  the  user/operator  data  input  burden 
have  not  been  employed  in  battlefield  automated  systems.  TACFIRE,  for  example, 
has  no  provisions  for  automatic  cursor  placement  during  error  correction  or 
for  skipping  over  optional  fields.  One  potentially  powerful  mechanism  for 
reducing  input  burden  is  conspicuously  absent  from  the  systems  studied  — 
creation  of  command  files  or  command  macros.  This  capability  is  particularly 
valuable  in  systems  with  a  heavy  emphasis  on  data  query  and  retrieval ,  such 
as  IISS.  The  utility  of  this  design  feature  in  message-handling  systems 
depends  heavily  on  the  kinds  of  uses  to  which  the  system  is  to  be  put  and  the 
likelihood  that  users/operators  will  repeatedly  perform  very  similar  message 
entry  operations. 

3.3  Interrupts  and  Work  Recovery.  Little  was  ascertained  in  this  analysis 
concerning  recovery  from  catastrophic  system  failure.  Procedures  for  dealing 
with  these  sorts  of  events  were  not  typically  stressed  in  system  documentation. 


Where  interrupts  were  caused  by  anticipatable  events,  such  as  movements 
of  the  system  from  one  field  location  to  another,  provisions  for  restart  seemed 
adequate.  It  should  be  noted,  however,  that  many  systems  presume  the  presence 
of  highly  skilled  system  operators  for  system  initialization  and  startup. 

This  dependency  may  cause  problems  in  crisis  situations. 

Both  of  the  message-oriented  systems  contain  provisions  for  placing  com¬ 
pleted  or  partially  completed  messages  in  a  buffer  pending  completion  of  higher- 
priority  activities.  Retrieval  of  these  stored  messages  permits  the  user- 
operator  to  proceed  as  though  no  interruption  had  occurred.  IISS  also  has 
provisions  for  storing  partially  completed  JINTACCS  messages.  As  it  is 
currently  configured,  however,  there  is  a  significant  problem  with  the  IISS 
procedure.  If  a  user/operator  starts  and  finishes  the  creation  of  a  JINTACCS 
message  without  interruption,  the  process  is  supported  by  permitting  the  user/ 
operator  to  fill  out  message  "blanks."  If  the  process  is  interrupted,  the 
partially  completed  message  may  be  stored  in  a  file  for  subsequent  completion. 

In  this  case,  however,  the  user/operator  can  no  longer  simply  fill  in  a 
message  "blank"  —  he  or  she  must  type  both  field  labels  and  entries  in  the 
appropriate  format. 

4.0  Message  Composition  Aids 

4.1  System  Design  Features.  Except  for  the  Automated  Run  Book  of  the 
DS4,  all  of  the  systems  studied  have  provisions  for  sending  and  receiving  at 
least  one  kind  of  message.  TCT  and  TACFIRE  are  message-oriented  systems; 
their  primary  purpose  is  to  permit  users/operators  to  easily  communicate  to 
other  Army  personnel  within  a  distributed  information  network.  IISS  is 
primarily  a  data  base  oriented  system,  but  includes  capabilities  for  sending 
and  receiving  both  JINTACCS  and  analyst -to-analyst  messages. 

All  three  of  these  systems  have  provisions  for  sending  and  receiving 
two  general  types  of  messages;  free  text  messages  and  highly  formatted 
messages.  In  TCT  and  TACFIRE,  the  free  text  messages  are  me^ily  another  type 
of  message.  In  IISS,  the  USER  MSG  option  is  used  to  send  free  text  analyst- 
to-analyst  messages,  while  the  IN  ANAL  option  is  used  for  generat-'ng  JINTACCS 
messages,  which  are  highly  formatted. 
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Techniques  for  generating  messages  are  similar  for  all  three  systems.  All 
use  "fill-in-the-blank"  method,  though  the  implementation  of  this  method  varies 
somewhat.  TCT  supports  the  creation  of  its  messages  with  data  entry  menus, 
while  the  other  two  employ  direct  entry  of  information  into  the  empty  spaces 
in  the  forms. 

All  of  the  message-handling  procedures  in  the  three  systems  have  cursor- 
oriented  editing  procedures.  Incorrect  or  undesired  values  are  altered  by 
placing  the  cursor  over  the  undesired  entry  and  overprinting  it.  Editing 
procedures  for  TCT  and  IISS  are  somewhat  more  convenient,  since  they  protect 
the  field  labels  of  the  message  data  entry  formats.  In  TACFIRE  data  element 
labels  can  be  overprinted  because  the  cursor  does  not  skip  automatically  past 
these  names.  Thus  a  user/operator  can  change  data  elements  either  inadvertently 
or  deliberately  by  overprinting  them,  thus  causing  errors  or  invalid  data 
base  entries. 

The  greatest  deficiency  in  system  design  for  message  composition  is  the 
lack  of  legal  values  information  available  for  TACFIRE  and  IISS.  If  users/ 
operators  forget  what  entries  are  valid  for  a  particular  message  element, 
there  is  no  alternative  to  consulting  hard  copy  reference  materials.  These 
manuals  can  be  easily  lost  or  mislaid,  and  the  positional  disparity  between 
printed  page,  keyboard,  and  screen  can  make  unnecessarily  difficult  the  trans¬ 
fer  of  information  from  the  reference  manual  to  the  appropriate  portion  of  the 
message  blank.  Neither  TACFIRE  nor  IISS  contain  pointers  to  portions  of  hard 
copy  references  dealing  with  individual  data  elements  or  particular  message 
types.  As  indicated  above,  TCT  does  not  exhibit  any  of  these  deficiencies, 
since  it  employs  menus  for  message  data  entry. 

4.2  Format  for  Alphanumeric  Messages.  The  appearance  of  highly  formatted 
messages  is  similar  for  all  three  systems  (recall  Figures  28,  29,  and  30) 
which  support  message  composition.  TACFIRE 's  message  blanks  are  somewhat  more 
densely  packed  them  those  of  the  other  two  systems,  probably  because  of  the 
limltod  screen  size  available  on  its  displays.  All  of  the  systems  use  virgules 
(slashes)  to  identify  subelements  of  message  data  entry  information;  this  is 
a  desirable  feature.  IISS  and  TACFIRE  both  indicate  the  maximum  allowable 
size  of  the  data  entry  fields  by  providing  "underlines"  for  each  field.  TCT 
does  not  employ  this  feature,  but  it  is  not  nearly  so  necessary  since  the  menu- 
oriented  message  compositon  of  TCT  is  not  vulnerable  to  string  length  errors. 
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There  is  one  problem  with  the  message  formats  in  all  three  systems  which 
could  cause  significant  degradation  of  message  output:  the  rigidity  of  the 
formats  themselves.  If  information  which  is  used  to  generate  the  messages 
always  arrives  in  the  same  format,  that  format  is  identical  to  the  appropriate 
portion  of  the  message  blank,  there  will  be  no  problem.  But  this  is  not 
always  the  case.  Information  can  be  received  via  either  voice  or  informal 
(free  text)  messages.  The  user/operator  must  then  skip  around  in  the  format 
on  the  display  screen,  or  else  follow  the  screen  format  and  skip  around  in  the 
incoming  message.  Either  approach  is  clumsy,  time-consuming,  and  prone  to 
error. 

4.3  Graphic  messages.  During  the  period  in  which  data  were  gathered 
for  this  analysis,  none  of  the  systems  studied  had  the  capability  for  con¬ 
structing  or  receiving  graphics  messages.  This  capability  is  planned  for  imple¬ 
mentation  in  TCT  for  early  1981,  but  no  final  information  on  its  form  is  avail¬ 
able.  The  IISS  terminals  (Sperry-Univac  1652' s)  have  graphics  capabilities, 
but  these  are  not  yet  used  in  IISS  operations. 

5.0  Data  Retrieval  Assistance 

5.1  Query  methods.  Three  of  the  systems  studied  have  some  form  of  data 
base  query  method:  DS4  Automated  Run  Book,  TACFIRE,  and  IISS.  TCT  is  almost 
wholly  message-oriented;  as  yet,  no  requirements  for  data  base  construction 
or  query  have  surfaced  in  TCT  development.  The  query  methods  for  the  other 
three  systems  are  radically  different. 

The  Automated  Run  Book  of  DS4  provides  the  least  comprehensive  query 
capability  of  the  three.  Since  the  ARB  is  essentially  a  software  "front  end" 
used  to  input  or  edit  data  and  to  create  job  control  language  for  batch 
computer  runs,  it  cannot  interact  directly  with  the  affected  files  in  any 
truly  transactional  sense.  Its  query  capabilities  are  limited,  therefore, 
to  generation  of  predefined,  periodic  "products." 

TACFIRE  provides  the  capability  to  interrogate  the  system's  data  bases 
through  special  query  messages,  which  are  similar  in  format  to  other  TACFIRE 
messages.  However,  because  of  the  severe  size  constraints  in  the  system's 
display  screens,  if  the  output  from  a  query  is  extensive  it  must  either  be 
output  in  multiple  messages  on  the  screen  or  else  output  to  the  printer. 
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In  either  event,  the  relatively  low  data  transmission  capabilities  of  the 
TACFIRE  communication  network  limit  the  amount  of  information  that  can  con¬ 
veniently  be  received  from  a  TACFIRE  QUERY. 

IISS  provides  the  most  comprehensive  query  capability  of  the  three 
applicable  Army  battlefield  automated  systems.  This  is  not  surprising,  since 
the  core  purpose  of  IISS  is  to  provide  for  storage  and  exploitation  of  ground 
order-of-battle  data.  IISS  provides  two  basic  query  methods: 


The  Man-Machine  Interface  Selection/Retrieval  Screen 
(Figure  31) .  This  is  essentially  a  fill-in-the-blanks 
support  to  GIM  queries.  "Hits"  from  this  retrieval  pro¬ 
cess  are  displayed  in  a  preformatted  index  list  (Figure 
32) ;  the  user /operator  can  examine  in  detail  any  of  the 
records  in  the  "hit"  list  by  light -penning  any  of  the 
displayed  items  in  the  index  list. 


CLASSIFICATION  ***CAVEAT*** 

RETRIEVAL  SCREEN  FDR  AIR  UNITS  FILE  (AUNFF) 


IDENTIFIED  UNIT(ID) 
UNIDENTIFIED  UNIT(lff)' 


+FHSTR(6) 

+PRSAT(6) _ _  _  ACTYP 

0BTYP(1)__"  _  ““  CALEG  (2) 

ACCND(5)  _  "  RMKEY  (5)__ 

(76)  ~  “  ACFTF(19) 

(76) :::::::::::::::::::::::: 


ORIGN  (2) 


Figure  31.  Example  of  a  Selection/Retrieval  Screen.  Redrawn  from  IISS  User's 
Manual,  p.  3-41.  (Note:  not  all  field  labels  are  included  in  this  figure 
because  the  photocopy  of  the  document  used  for  analysis  was  unreadable.) 


b.  The  GIM  language.  This  is  easily  the  more  powerful  of  the 
two  query  methods  available  in  IISS,  allowing  the  user/ 
operator  to  exploit  the  ground  order-of-battle  data  base 
in  almost  any  conceivable  way.  The  GIM  language  includes 
command  terms  for  at  least  four  functions. 

1.  verbs  indicate  to  the  system  what  activities  are 
to  be  performed. 
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CLASSIFICATION  ***CAVEAT*** 

SHORT  OUTPUT  SCREEN  FOR  AIR  UNITS  (AUNTF) 


AUNTF 

EQATH 

EQPOH  ACFTF 

PRTOT 

PHTOT 

CALEG 

AUNIT00002 

I  AIRUNIT03 
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49 

AC  FT 
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IT 
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IT 

AUNIT00004 

I  AIRUNIT05 
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47 

ACFT 
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IT 

AUNIT00006 

I  A I  RUN  I T07 
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ACFT 
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0 

IT 

AUNIT00007 

I  AIRUNIT08 
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44 

ACFT 

176 

0 

IT 

AUNIT00008 

I  AI RUNIT09 
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43 

ACFT 

180 

0 

IT 

AUNIT00009 

I  AI RUN I T1 0 

9 

42 

ACFT 

184 

0 

IT 

AUNIT000010 

I  AI RUN IT! 1 

10 

41 

ACFT 

188 

0 

IT 

AUNIT000011 

I  AIRUNIT12 

11 

40 

ACFT 

192 

0 

IT 

AUNI T00001 2 

I  AIRUNIT13 

12 

39 

ACFT 

196 

0 

IT 

AUNIT000013 

I  AIRUNIT14 

13 

38 

ACFT 

200 

0 

IT 

AUNIT00001 4 

I  IARUNIT15 

14 

37 

ACFT 

204 

0 

IT 

AUNIT0000I 5 

I  AIRUNIT1 6 

15 

35 

ACFT 

209 

0 

IT 

AUNIT00001 6 

I  AIRUNIT17 

16 

35 

ACFT 

212 

0 

IT 

^  _ / 

Figure  32.  IISS  Index  List.  Redrawn  from  IISS  User's  Manual,  p.  3-41. 


2.  Qualifiers  indicate  under  what  circumstances  certain 
activities  a^e  to  be  performed.  Conditional  situations 
may  be  defined  mathematically,  list -positionally , 
logically,  or  in  combinations. 

3.  System  literals  identify  values  (defined  as  literals) 
which  are  necessary  for  system  operation. 

4.  Connective  bridge  terms  and  phrases  in  GIM  commands, 
defining  how  they  should  be  combined  in  order  to 
yield  the  desired  results. 

GIM  queries  are  more  flexible  and  powerful  than  MMJ  queries.  A  user/operator 
who  wishes  to  fully  exploit  the  capabilities  of  IISS  is  therefore  forced  to 
learn  GIM.  This  requires  the  memorization  of  137  GIM  language  terms,  the 
grammatical  and  syntactical  rules  for  using  those  terms,  and  the  mnemonics  and 
legal  values  for  the  TACOB  (or  other  OB  file)  record  elements.  These  require¬ 
ments  impose  an  excessive  memory  burden  on  intelligence  analysts/users  who 
are  not  computer  specialists. 

None  of  the  systems  studied  employs  query  files  or  query  macros  to  per¬ 
mit  users/operators  to  store  "canned”  queries  for  subsequent  use. 
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5.2  Query  structures.  Of  the  systems  studied,  only  IISS  contains  suf¬ 
ficiently  powerful  query  capabilities  to  warrant  consideration  of  query 
structures.  Using  either  the  MMI  or  GIM  language  capabilities  of  IISS, 
users/operators  can  define  queries  in  a  number  of  ways: 

a.  Simple  queries,  based  on  single-item  specifications  in  the 
query.  For  example,  the  user/operator  might  wish  to 
examine  the  order-of -battle  record  for  a  particular 
enemy  unit.  By  entering  the  appropriate  GIM  command  and 
the  unit  I.D.  for  that  unit,  the  user/operator  can  list 
the  contents  of  the  record  for  only  that  enemy  unit. 

b.  Conditional  queries,  formed  by  combining  specified  char¬ 
acteristics  of  a  hypothetical  unit.  Conditions  may 

be  specified  methematically  (e.g.,  "2000  persons"), 
relationally  (e.g.,  "more  than  2000  persons”)  or  on  the 
basis  of  string  matches  (e.g.,  "equipment  type  7-72,-" 
"echelon-regiment;"  "alternate  name  =  BIGREDZ") .  Logi¬ 
cal  operators  are  also  permitted  (e.g.,  "all  units  with 
more  than  2000  persons  AND  equipment  type  T-72") . 

c.  Geographic  queries ,  wherein  the  user/operator  defines  a 
geographic  region  and  extracts  from  the  data  base  all 
information  with  specified  characteristics  from  that 
region.  Both  circle  searches  and  n^  sided  polygon 
searches  (z  <  n  <  14)  are  provided. 

Comoining  GIM  commands  (either  directly  through  GIM  language  mode  or 
indirectly  via  the  MMI)  and  characteristics  of  the  data  base  being  queried 
clearly  provides  IISS  users/operators  with  a  powerful,  flexible  query  mech¬ 
anism.  Query  structures  possible  are  therefore  only  trivially  constrained 
by  the  available  query  tools.  But  this  power  and  flexibility  do  not  come 
without  cost.  After  deciding  what  sort  of  query  to  perform,  the  user/operator 
must  define  the  structure  of  the  data  base  search  and  retrieval  to  be  performed. 
Except  for  the  geographic  search  capability  IISS  has  virtually  no  "canned" 
query  structures.  This  forces  its  users/operators  to  learn  how  to  generate 
their  own  query  structures. 

It  is  perhaps  constructive  to  compare  IISS  with  the  Automated  Run  Book 
of  DS4  with  respect  to  their  provision  of  prestructured  queries.  The  ARB 
is  not  nearly  so  flexible  a  system  as  IISS;  its  users/operators  can  perform 
only  those  activities  listed  in  its  command  menus.  To  generate  a  STOCK 
STATUS  REPORT,  for  example,  the  Run  Book  user/operator  merely  selects  that 
item  from  the  DSC  WEEKLY  REPORTS-PROCESSES  menu  (Figure  33) .  The  report  is 
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=========- ====OSC  WEEKLY  REPORTS-PROCESSES============ 

0  I  need  HELP  (FUNCTIONAL  GUIDANCE) 

1  We  need  to  do  a  WEEKLY  CONSOLIDATION 

2  (SS)  We  need  to  do  a  STOCK  STATUS  REPORT 

3  We  need  to  do  a  WEEKLY  REPORTS  PROCESS 

99  It  is  time  to  TERMINATE  this  session. 


->  Please  enter  the  line  number  which  describes  what 
you  want  to  do  <- 


V 


J 


Figure  33.  The  menu  of  weekly  reports-processes  that  are  presented  by  the 
Automated  Run  Book. 

then  generated  by  DS4;  rules  for  selecting,  combining,  extracting,  formatting, 
and  printing  the  data  are  supplied  by  DS4  software.  The  Run  Book  user/ operator 
need  not  be  concerned  at  all  with  these  rules,  and  the  interaction  to  specify 
a  STOCK  STATUS  REPORT  would  take  about  15  seconds. 

If  it  is  assumed  for  purposes  of  illustration  that  IISS  files  contained 
admin/log  data  like  that  in  DS4,  rather  than  order-of-battle  data,  the  IISS 
user/operator  would  have  a  far  more  difficult  task  than  would  the  Run  Book 
user/ operator.  If  no  special  provisions  for  creation  of  a  STOCK  STATUS  REPORT 
were  made,  the  IISS  user/operator  would  have  to: 

a.  Ascertain  what  data  items  would  be  used  in  generating 
a  STOCK  STATUS  REPORT. 

b.  Ascertain  how  data  items  would  be  combined  to  yield 
the  information  required  in  a  STOCK  STATUS  REPORT. 

c.  Identify  criteria  for  including  or  excluding  the  con¬ 
tents  of  individual  records  from  the  STOCK  STATUS 
REPORT . 
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d.  Ascertain  the  required  output  format  for  a  STOCK  STATUS 
REPORT. 

e.  Enter  GIM  commands  for  both  data  extraction  (query) , 
data  processing,  and  report  format. 

It  is  entirely  conceivable  that  this  process  would  require  several  hours, 
rather  than  a  few  seconds. 

It  would  be  inappropriate  to  conclude  from  this  discussion  that  IISS  is 
a  "bad"  system  and  the  DS4  Automated  Run  Book's  a  "good"  one.  The  systems 
are  in  different  functional  areas,  and  are  driven  by  completely  different 
sets  of  user  and  functional  requirements.  Note  also  that  IISS  would  provide 
the  user/ operator  with  vastly  increased  flexibility  in  defining  and  organiz¬ 
ing  products.  The  IISS  user/operator  could,  for  example,,  generate  a  report 
identical  in  format  to  a  STOCK  STATUS  REPORT,  but  limited  in  content  to  only 
a  certain  class  of  stock  items.  This  would  be  impossible  in  the  Run  Book 
without  substantive  modification  of  the  DS4  software. 

The  comparison  of  the  IISS  and  Run  Book  designs  does,  however,  highlight 
a  distinct  difference  in  "query"  philosophy: 

a.  The  Run  Book  places  severe  constraints  on  the  range  of 
"query"  structures  permitted. 

b.  IISS  places  almost  no  constraints  on  the  query  structures 
which  its  users/operators  may  employ.  The  number  and 
variety  of  query  products  are  limited  only  by  the  imagina¬ 
tion,  requirements,  and  skills  of  the  users/operators. 

This  flexibility  extracts  a  penalty  in  terms  of  the  time 
and  effort  required  to  describe  the  characteristics  of 
the  required  product  to  the  ADP  system. 

It  is  possible,  even  likely,  that  the  operational  requirements  of  order- 
of-battle  data  absolutely  require  the  flexibility  provided  in  IISS.  It  would 
be  appropriate  to  limit  the  options  provided  to  experienced  user/operator 
in  generating  precisely  the  kinds  of  queries  which  he  or  she  desires.  Develop¬ 
ing  and  incorporating  more  "canned"  query  structures  into  IISS  might,  however, 
yield  significant  benefits,  particularly  if  say,  10  or  15  such  structures 
would  account  for  a  majority  of  the  queries  actually  made  by  IISS  users/ 
operators.  Incorporating  these  query  structures  would  require  investigation 
of  the  kinds  of  activities  typically  performed  by  GOB  analysts.  Such  an 
investigation  is  beyond  the  scope  of  this  project,  but  should  be  conducted  if 
the  thrust  of  IISS  modifications  to  enhance  the  usability  of  the  system  is  to 
be  clarified.  Lessons  learned  in  IISS  are  likely  to  be  transferable  to  other 
Army  battlefield  automated  systems. 
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6. 


Glossaries 


6.1  Standard  terms.  Terms  used  in  battlefield  automated  systems  should 
be  standard  both  within  and  across  systems  and  should  conform  to  doctrinal 
usage.  This  statement  seems  so  obvious  as  to  be  unworthy  of  mention.  However, 
both  of  these  maxims  are  violated — and  frequently.  TACFIRF.  presents  consider¬ 
able  difficulty  with  respect  to  provision  of  standard  terms:  10  volumes  are 
required  to  describe  procedures  for  using  225  message  formats  incorporating  over 
900  data  elements,  their  element  names,  and  legal  entries  for  their  names. 

Just  about  every  problem  that  could  be  imagined  with  standard  terms  is  evident 
in  TACFIRE : 

a.  Multiple  names  for  the  same  data  element. 

b.  Different  meanings  for  the  same  data  element  name  in 
different  messages. 

c.  Lack  of  on-line  assistance  for  "decoding"  data  elements. 

d.  Similar  but  slightly  different  message  formats  where  one 
constant  format,  using  consistent  terms,  would  do. 

e.  Functions  requiring  similar  formats  labeled  just  enough 
differently  at  different  positions  to  cause  confusion  (e.g., 

AFU ; BAMOUP  for  BN  and  AFU;AMOUPD  for  DIVARTY) . 

f.  Codes  which  differ  from  doctrinal  codes  (see  Figure  for 
examples) . 


TACFIRE 


MEANING 


Restrictive  Fire  Line 
Coordinated  Fire  Line 
Free  Fire  Aree 
Restrictive  Fire  Are* 

No  Fire  Are* 
Controlled  Supply  Rate 
Airspace  Coordination  Area 
Aim  Point 

Forward  Edge  of  Battle  Area 


FM  6-20 


Figure  34.  Examples  of  Differences  Between  TACFIRE  and  Doctrinal  codes. 
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The  Automated  Run  Book  uses  standard  terms  in  its  menus  and  prompts 
but  creates  some  minor  problems  by  ambiguous  use  of  pronouns  and  verbs  which 
could  contribute  to  problems  for  unsophisticated  users/operators. 

IISS  has  some  good  features  with  respect  to  standard  terms.  For  example,  it 
automatically  calculates  and/or  inserts  data  values  for  geocoordinates,  date 
of  update,  and  position  track  information  when  these  are  available  from  stand¬ 
ard  system  information.  In  the  main,  terminology  in  the  MASTER  MENU,  the  GIM 
MENU,  and  the  IISS  HELP  listing  is  consistent.  In  general,  however,  terminol¬ 
ogy  within  IISS  could  have  greater  consistency — for  fixed  and  variable  func¬ 
tion  key  labels,  option  switches  and  the  record  element  levels  of  TACOB  data 
sets.  Also,  IISS  uses  at  least  three  separate  command  methods — the  TELETYPE 
mode,  the  MMI  forms,  and  the  GIM-II  language — and  there  are  some  instances 
of  completely  different  terminology  within  these  to  designate  the  same  func¬ 
tion. 

As  shown  in  Figures  7  and  8,  systems  differ  not  only  in  the  way  in  which 
given  functions  are  accomplished  but  also  in  the  terminology  applied  to  label 
such  things  as  function  keys  or  to  call  out  commands  when  functions  are  per¬ 
formed  in  the  same  manner.  Just  as  users/operators  shift  from  one  position 
to  another  within  a  system,  they  can  be  expected  to  shift  across  systems. 

Serious  penalties  can  be  expected  to  be  paid  in  terms  of  retraining,  user/ 
operator  error,  mission  delay  and  even  abort  when  unnecessary  inconsistencies 
in  standard  terminology  are  allowed  to  persist  across  systems. 

6.2  Character  S8tS  and  label S .  Most  systems  use  the  26  letters  of  the 
alphabet  and  the  digits  0  through  9  for  data  entry,  although  the  key  arrange¬ 
ments  for  these  data  entries  may  vary  considerably  across  systems  and  even 
within  systems  (see  the  discussion  of  this  under  1.3  Function  Keys) .  Most 
systems,  in  addition,  use  a  set  of  special  symbols  as  delimiters,  commands,  or 
operators.  Most  of  these  symbols  have  a  "conventional"  meaning  that  derives 
from  some  grammatic  or  arithmetic  convention.  Both  the  set  of  symbols  used 
and  their  meaning  may  vary  considerably  from  system  to  system — often  without 
apparenc  reason. 

There  are  at  least  five  problems  commonly  associated  with  character  sets 
and  labels : 

a.  Inconsistent  usage  across  systems. 
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b.  Multiple  meanings  or  purposes  for  a  given  symbol. 

c.  Multiple  symbols  used  for  the  same  purpose  or  meaning. 

d.  Usage  which  is  outside  the  bounds  of  the  user's/operator's 
knowledge /experience . 

e.  Usage  which  is  not  in  agreement  with  "convention." 

Figure  9  demonstrates  the  first  type  of  problem  with  respect  to  common 
non-alphabetical  symbols.  Note  that  the  colon  (:)  is  used  in  TACFIRE  and  TCT 
as  a  single-valued  field  delimiter,  while  IISS  uses  the  virgule  (/)  for  this 
purpose  (and  uses  the  colon  to  separate  the  switch  from  the  switch  parameters) . 
Figure  10  demonstrates  inconsistent  usage  of  Boolean/relational/logical  charac¬ 
ter  sets  across  systems. 

Problems  of  the  second  type ,  multiple  meanings  or  purposes  for  a  given 
symbol,  are  also  demonstrated  in  Figure  9.  In  this  respect,  TACFIRE  and  TCT 
are  "cleaner"  than  the  other  systems  examined  and,  from  the  data  presented  in 
Figure  9,  Army  systems  in  general  are  better  than  the  non -Army  systems  examined. 

IISS  uses  the  virgule  (/)  as  both  a  field  delimiter  and  as  the  arithmetic  opera¬ 

tor  for  division,  however. 

A  number  of  examples  of  the  third  type  of  problem  are  evident  in  Figures 
9  and  10.  For  example,  dates  can  be  written  as  day  (2  digits) ,  time  (4  digits) , 
zone  (1  letter) ,  month  (3  letters) ,  and  year  (2  digits)  in  one  continuous 
stream  in  TCT.  Dates  can  also  be  written  as  month  (2  digits  followed  by  /) , 

day  (2  digits  followed  by  /)  ,  and  year  (2  digits)  in  MAGIS.  MAGIS  also  uses 

the  virgule  (/)  to  separate  hours,  minutes,  and  seconds;  as  a  command  prefix; 
and  to  separate  mnemonics.  While  these  uses  are  not  in  conflict  with  each 
other,  they  do  make  the  system  and  the  user/operator  lean  heavily  on  one  single 
symbol . 

The  kinds  of  problems  which  result  when  users/operators  are  required 
to  use  symbology  with  which  they  are  unfamiliar  or  with  which  they  lack  exper¬ 
ience  or  knowledge  have  been  discussed  with  respect  to  the  "greater  than" 
and  "less  than"  symbols,  (>)  and  (<)  respectively,  in  the  text  associated  with 
Figure  10  on  page  25.  A  backwards  interpretation  of  these  two  symbols  is  not 
unusual,  even  with  people  who  can  truly  be  expected  to  know  better.  Erroneous 
use  of  Boolean/relational/logical  operators  can  be  avoided  by  replacement  with 
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codes  (GT  for  greater  than,  LT  for  less  than)  as  are  employed  in  IISS.  In  fact, 
IISS  circumvents  the  whole  issues  of  Boolean/relational/logical  symbology  by 
letter  code  replacements. 

One  noteworthy  example  of  this  type  of  problem  is  found  in  the  DS4  Auto¬ 
mated  Run  Book,  despite  its  otherwise  relatively  standard  and  acceptable  usage 
of  character  sets  and  labels.  Here  the  (@)  key  is  used  for  backspacing  when 
the  user/operator  wants  to  correct  a  typographical  error.  Convention  tells  us 
that  the  key  symbol  for  backspacing  should  be  (< — )  and  that  the  (@)  symbol 
usually  means  "at  or  about,"  "approximate,"  or  "rate  per"  but  in  ho  way  indicates 
to  the  user/operator  to  backspace  and  correct  a  typographic  error. 

6.3  Glossary  availability  and  use.  To  be  of  most  value,  glossaries 
should  be  available  on-line,  should  be  logically  organized  for  ease  of  access, 
and  should  be  available  in  usable  "chunks"  and  in  as  many  versions  as  dictated 
by  user/operator  requirements. 

Glossary  availability  and  use  is  one  category  where  the  review  of  TACFIRE 
led  to  the  conclusion  that  a  human  factors-related  problem  could  result  in  system 
failure.  TACFIRE  glossaries  are  contained  exclusively  in  off-line  documentation; 
the  computer  provides  no  on-line  definitions  of  data  element  names  and  no  on¬ 
line  dictionaries  of  legal  terms.  As  noted  in  the  discussion  of  standard 
terms,  there  are  so  many  names  and  terras  that  no  user/operator  could  reason¬ 
ably  be  expected  to  memorize  more  than  a  relatively  small  percentage  of  them. 

To  obtain  assistance  for  any  term  in  a  message,  the  user/operator  must  turn 
attention  from  the  computer  to  off-line  manuals — and  then  upon  returning  to 
the  screen,  relocate  the  area  of  the  screen  being  attended  to.  Switching 
attention  between  the  screen  and  documents  consumes  time  and  increases  the  like¬ 
lihood  of  error.  Even  more  devastating,  in  a  fluid  tactical  situation,  if  the 
off-line  documents  should  be  lost,  one  could  easily  imagine  that  a  situation 
might  arise  in  which  users /op era tors  would  need  to  enter  messages  beyond  the 
normal  (and  presumably  well-learned)  repertoire.  Deprived  of  their  primary 
job  aid — the  document — users/operators  could  only  guess  at  element  name 
definitions  and  at  legal  entries .  In  this  event ,  the  system  could  fail  to 
perform  its  mission. 

IISS  provides  nine  separate  terms  and  code  sets  which  can  be  considered 
glossaries .  These  run  a  spectrum  from  always  available  key  labels  to  never 
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either  event,  the  accuracy  of  the  data  base  may  be  degraded,  leading  to  errors 
in  system  outputs.  The  rate  of  artillery  information  processing  may  be  reduced; 
overall  field  artillery  effectiveness  may  be  reduced. 

The  Automated  Run  Book,  in  general,  uses  abbreviations  and  codes  in  the 
data  reduction  function  but  not  in  the  production  processing  function.  Even 
in  data  reduction,  abbreviations  and  codes  are  used  only  in  data  fields  of 
transaction  card  images.  Not  using  abbreviations  and  codes  has  potential 
for  system  degradation  too,  since  many  codes  and  abbreviations  can  quickly 
become  well  integrated  into  user/operator  processing  routines.  As  shown  in 
Figure  35,  code  options  which  are  standard  in  the  supply  function  are  avail¬ 
able  in  the  As  Required  Reports-Process  menu;  the  DS4  user/ operators  cannot 
use  these  codes  but  instead  must  use  arbitrary  number  codes. 


- -  A 

=..«»»»— DS4  AS  REQUIRED  REPORTS-PROCESSES——— 

0  I  need  HELP  (FUNCTIONAL  GUIDANCE) 

1  (AR)  We  need  to  do  a  ASL  REPLENISHMENT  (STAND  ALONE) 

2  (LS)  We  need  to  do  a  LOCATION  SURVEY  PROCESS 

3  (MC)  We  need  to  do  a  MASS  CANCELLATION  PROCESS 

4  (PC)  We  need  to  do  a  PARAMETER  CHANGE  PROCESS 

5  (SI)  We  need  to  do  a  SPECIAL  INVENTORY 

6  (SX)  We  need  to  do  a  SIMS-X  PROCESS 

7  (UD)  We  need  to  do  a  UNIT  DEMAND  HISTORY  EXTRACTION  AND  INSERTION  PROCESS 

8  We  need  to  do  a  CYCLIC  ERROR  LIST 

9  We  need  to  do  a  EDIT-ARRANGE  ABEND  SORT  I 

10  We  need  to  do  a  EDIT-ARRANGE  ABEND  SORT  2 

99  It  Is  time  to  TERMINATE  THIS  SESSION 

->  Please  enter  the  line  number  which  describes  what  you  want  to  do  <- 


V _ / 


Figure  35.  The  menu  for  As-Required  Reports-Processes  in  the  DS4  Automated 
Run  Book. 
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available  on-line  display  of  such  things  as  legal  values.  As  in  TACFIRE ,  loss 
of  documentation  (although  probably  much  less  likely  than  for  TACFIRE)  could 
result  in  grave  jeopardy  to  the  mission. 

In  TCT ,  on  the  other  hand,  standard  terms,  character  sets  and  labels, 
glossaries,  and  abbreviations  and  codes  used  in  the  standard  message  formats 
are  presented  to  the  user/ 'operator  through  menus  and  prompts.  Although  glos¬ 
sary  definitions  had  not  yet  been  made  available  at  the  time  of  the  review 
of  the  DS4  Automated  Run  Book,  developer  personnel  indicated  that  HELPS  to  be 
provided  by  the  Logistics  Center  (LOGCEN)  will  include  glossary  definitions 
for  on-line  display. 

6.4  Abbreviations  and  codes.  Abbreviations  and  codes  are  used  extensively 
in  battlefield  automated  systems:  message  formats  almost  always  require  them. 
Even  the  TCT  FREE  message  format  uses  abbreviations  and  codes  in  its  heading 
information.  Doubtless,  the  message  text  proper  will  contain  abbreviations 
and  codes  for  the  simple  reason  that  military  systems  are  replete  with  them. 

In  truth,  our  total  language  has  become  one  that  accepts  abbreviations  and  codes 
as  "words."  While  computer  systems  cannot  be  totally  blamed  for  that  situation, 
they  have,  nevertheless,  contributed  to  it. 

The  problem  is  not  that  abbreviations  and  codes  are  so  widely  used, 
but  that  they  are  so  poorly  and  so  inconsistently  designed.  The  TACFIRE 
situation  is  representative  of  these  problems.  The  TACFIRE  glossary  contains 
a  mixture  of  full  words  (e.g.,  SPHERE,  FUZE),  abbreviations  (e.g.,  COORD,  FZE) , 
mnemonics  (e.g.,  GZ,  DTG) ,  and  codes  (e.g.,  D,  LINA).  Most  element  names  in 
TACFIRE  formatted  messages  consist  of  abbreviations,  mnemonics,  or  codes. 

But  no  consistent  rule  for  formulating  these  element  names  has  been  found. 

This  lack  of  consistency  complicates  the  user's/operator's  attempts  to  decode 
element  names  and  forces  the  user/operator  to  decode  abbreviations,  mnemonics, 
and  codes  from  memory — or  else  refer  to  off-line  manuals.  Variations  in 
element  names  (see  6.1  Standard  Terms)  from  one  format  to  another  create  a 
distinct  possibility  for  confusion  of  common  elements  from  message  to 
message.  If  the  user/operator  attempts  to  decode  element  names  from  memory, 
the  probability  of  erroneous  decoding  is  increased.  Errors  in  decoding  may 
lead  to  erroneous  inputs.  If  the  user/operator  decodes  element  names  by 
reference  to  manuals,  time  required  to  complete  transactions  is  increased. 


76 


Most  IISS  code  sets  employ  mnemonic  abbreviations.  The  rules  for  forming 
these  mnemonic  codes  are  not  rigorous  although  they  do  seem  reasonably  logical. 
There  are,  however,  some  exceptions.  In  the  TACOB  record  element  abbreviations, 
for  example,  the  term  "message"  is  abbreviated  in  the  following  ways: 


CODE 
MORIC 
ACMSG 
MI DENT 
MGTXT 


MEANING 

Message  Origination  or  Originator 
Message 

Message  Identifier 
Message  Text 


The  use  of  several  different  methods  for  creating  mnemonic  abbreviations  results 
in  dissonant  habit  formation  patterns — resulting  in  an  effective  memory  loading 
which  is  much  higher  than  that  which  would  be  required  to  learn  a  consistently 
designed  set  of  codes.  Inconsistent  codes  are  more  difficult  to  recall,  requir¬ 
ing  users/operators  to  access  HELP  files  or  refer  to  IISS  documentation.  Diffi¬ 
culty  in  recalling  codes  is  also  likely  to  increase  input  error  rate.  The  normal 
difficulty  in  recalling  codes  from  a  large  code  set  is  exacerbated  by  the 
inconsistency  in  code  sets.  With  an  increased  error  rate  caused  by  inconsistent 
codes,  delayed  delivery  of  intelligence  information  to  battlefield  commanders 
will  result. 


Part  of  the  IISS  problem  with  abbreviations  and  codes  is  its  "richness" 
of  codes.  For  example,  in  addition  to  the  multiple  codes  for  "message"  shown 
above,  there  are  the  following  codes  for  variations  in  the  meanings  of  "country" 
and  "equipment" : 


CODE 

MEANING 

CCNTY 

Country 

of 

Control 

CALEG 

Country 

of 

Allegiance 

CNTRY 

Country 

of 

World 

COLOC 

Country 

of 

Location 

NCNTY 

Country 

of 

Nationality 
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CODE 

MEANING 

EFUNC 

Equipment  Function 

EQATH 

Equipment  Authorized 

EQPOH 

Equipment  on  Hand 

EQTYP 

Equipment  Type 

EUSER 

Equipment  User 

7.  Error  Handling 

7.1  Error  prevention  techniques.  Most  battlefield  automated  systems  incor¬ 
porate  features  which  will  prevent  user/operator  error.  Few  do  enough,  but 
there  are  some  good  and  even  some  clever  error  prevention  techniques  employed. 

The  Automated  Run  Book  incorporates  some  good  error  prevention  techniques. 

In  the  production  processing  function,  there  is  a  recap  at  the  end  of  a  menu 
selection  sequence  which  should  reduce  the  probability  of  invoking  DS4  cycles 
inappropriately.  Its  use  of  menus  also  reduces  errors  because  they  display 
all  legal  values  and  thereby  reduce  the  memory  burden  on  the  user.  The  use  of 
questions  to  elicit  ECL  parameter  information  helps  to  prevent  entering  the 
wrong  kind  of  data.  For  example,  asking  for  a  date  relieves  the  operator  of 
the  necessity  to  remember  that  Data  Field  Number  1  requires  a  date  rather  than 
some  other  type  of  information.  Also,  in  the  data  entry  mode  of  the  data  reduc¬ 
tion  function,  underlines  are  used  to  indicate  the  length  of  each  data  field, 
with  each  underline  being  replaced  by  the  input  character  as  data  entry  proceeds. 
Indicating  field  length  in  this  manner  is  useful  in  two  ways: 

a.  It  cues  the  user  as  to  the  type  of  data  to  be  entered. 

b.  If  the  user  inadvertently  omits  one  or  more  characters,  the 
presence  of  underlines  at  the  end  of  the  field  provides  a 
cue  to  review  the  data  field  and  correct  the  error. 

TACFIRE  appears  to  incorporate  only  one  on-line  error  prevention  technique: 
data  element  names.  However,  as  noted  in  6.1  Standard  terms,  the  sheer  volume, 
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redundancies,  and  inconsistencies  in  these  element  names  will  degrade  rather 
than  enhance  user/operator  performance. 

For  TCT,  no  specific  routines  for  error  prevention  were  identified.  How¬ 
ever,  the  availability  of  legal  data  entry  items  via  the  menus  contributes 
directly  to  error  prevention. 

IISS  contains  a  number  of  techniques  designed  to  prevent  errors  of  com¬ 
mand  and  data  input: 

a.  On  both  MMI  (process  control)  and  full  record  displays 
(data  entry)  the  field  size  indication  shows  the  user 
unequivocally  how  many  characters  can  be  entered.  There 
is,  however,  generally  no  indication  of  whether  this 
number  of  characters  is  the  maximum  number  allowed  or 
the  only  number  allowed. 

b.  The  use  of  light  pens  for  command  and  file  selection 
allows  the  user/operator  to  select  from  options  which  are 
being  viewed  directly  rather  than  by  reading  or  recalling 
commands/data  and  entering  the  commands  at  the  terminal 
keyboard. 

c.  Presentation  of  data  element  labels  reduces  the  memory 
burdens  on  users/operators  by  eliminating  the  necessity 
for  recall  of  record  element  mnemonic  labels. 

d.  Which  screen  area  of  the  SU  1652  is  currently  active  is 
indicated  to  the  user/operator.  This  reduces  the  probabil¬ 
ity  that  data  will  be  entered  into  an  incorrect  screen 
area. 

e.  Automatic  creation  of  data  values  such  as  date  and  geo¬ 
graphic  coordinates  reduces  the  burden  on  the  operator. 

A  concomittant  effect  is  reduction  of  the  number  of 
items  which  the  user  must  enter,  thus  reducing  the 
opportunity  for  error. 

f.  VFK  labels  are  lit  when  they  are  active,  thus  assuring 
that  the  user/operator  will  not  waste  time  or  cause  an 
error  by  pressing  VFKs  which  are  not  currently  available. 

g.  The  presentation  of  "switch"  options  on  MMI  forms  assures 
that  the  user  is  constantly  presented  with  all  legal  values 
where  switch  options  are  available. 

h.  Any  of  seven  formats  can  be  used  for  entry  of  dates.  The 
first  of  January,  1981  can  be  entered  in  any  of  the 
following  forms. 


79 


1.  January  1,  1981 

2.  1  Jan  1981 

3.  1  Jan  81 

4.  1-1-81 

5.  1/1/81 

6.  1  January,  1981 

7.  l-Jan-81 


This  reduces  the  likelihood  of  error  in  date  entry, 
thereby  reducing  processing  time  and  providing  accurate 
date  information  in  IISS  intelligence  products. 

7.2  Error  detection  techniques.  In  terms  of  detecting  errors  which  are 
input  into  the  system,  the  Automated  Run  Book  again  incorporates  good  tech¬ 
niques.  By  the  use  of  range  checks,  legal  value  checks,  and  cross-field 
checks  wherever  possible  the  probability  of  errors  contaminating  the  DS4  data 
base  is  greatly  reduced.  In  addition,  the  program  checks  each  field  as  it  is 
entered,  rather  than  waiting  for  the  entire  transaction  to  be  completed  before 
beginning  error  checking  procedures.  This  feature  is  particularly  good,  because 
it  provides  an  immediate  opportunity  for  the  user  to  correct  each  error. 

Only  minimal  detection  of  message  entry  or  system  operation  error  is 
provided  on  TCT.  The  operator  alerts  which  appear  on  the  plasma  screen 
provide  indications  of  invalid  entry  and  identify  certain  function  key  opera¬ 
tions  which  should  be  performed.  But  both  operator  and  system  alerts  are 
more  precisely  "alerts"  than  error  detection  in  that  they  advise  about  status 
or  what  needs  to  be  done. 

The  GIM  DBMS  employed  in  IISS  provides  a  number  of  capabilities  for  error 
detection  to  maintain  data  base  integrity: 

a.  The  system  checks  the  input  to  determine  whether  the 
character  string  entered  is  of  appropriate  length.  GIM 
can  check  for  both  maximum  and  minimum  string  length 
limitations, 

b.  If  input  values  are  to  be  limited  to  a  small  number  of 
predetermined  values  (e.g. ,  H  for  high,  M  for  medium, 

L  for  low) ,  GIM  can  test  to  determine  whether  the  input 
contains  one  of  these  legal  values. 
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c.  ■  aere  the  number  of  legal  values  for  a  record  element 
i'i  large,  the  GIM  software  can  check  the  input  string 
against  a  table  of  legal  values.  This  technique  is 
used  to  evaluate  country  code  inputs  in  IISS,  for  example. 

d.  Relational  and  arithmetic  rules  are  applied  to  evaluate 
data  entry  against  other  data  already  contained  in  the 
TACOB  data  set,  thereby  providing  a  data  validity  check. 

e.  Some  data  elements  in  TACOB  files  can  only  be  entered  if  a 
corresponding  data  element  is  also  entered.  For  example, 
when  a  new  location  is  entered  to  a  EUNITS  record,  the 
corresponding  "change  location  date"  must  also  be  entered. 

This  assures  that  the  USAREUR  analysts  will  know  how  current 
position  reports  are. 

TACFIRE  also  performs  no  error  checking  until  a  message  is  completed  and 
entered  for  processing.  Then,  it  checks  the  message  one  field  at  a  time.  If 
an  error  is  detected,  an  error  message  is  displayed  (h'  ’ever,  see  7.3  Error 
feedback)  and  processing  of  the  message  stops.  The  user/operator  corrects 
the  erroneous  entry  (see  Section  7.4  Error  correction/recovery) ,  and  error 
checking  continues.  The  machine  provides  no  indication  of  multiple  errors, 
detecting  the  next  error  only  after  the  previous  error  has  been  corrected. 

This  procedure  is  a  needless  annoyance  to  the  user/operator,  and  delays  the 
completion  of  transactions. 

7.3  Error  feedback  techniques.  All  of  the  BASs  examined  were  found  want¬ 
ing  with  respect  to  error  feedback.  Error  feedback  is  the  weakest  aspect 
of  the  Automated  Run  Bock's  error  handling  features.  In  general,  the  Run  Book's 
error  feedback  consists  of  an  audible  "beep"  from  the  terminal  and  then  a 
recovery  message.  But,  the  recovery  message  indicates  only  what  are  valid 
entries;  it  does  not  tell  the  user/operator  what  the  incorrect  entry  was. 

While  making  the  determination  of  what  the  incorrect  entry  was  may  not  always 
be  difficult,  the  necessity  to  make  that  determination  provides  another  oppor¬ 
tunity  to  commit  an  error. 

TACFIRE  error  messages  in  general  also  contain  little  or  no  diagnostic 
information.  To  discover  the  cause  of  an  error,  the  user/operator  must  either 
page  back  to  the  error  location  or  read  an  error  code  from  a  panel  on  the  main 
computer.  This  code  is  displayed  in  binary  lights;  the  user/operator  must  con¬ 
vert  the  binary  code  to  octal,  and  then  look  up  the  octal  code  in  a  off-line 
manual  to  obtain  error  diagnostics.  The  machine's  error  feedback  facilities 
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force  the  user/operator  to  divide  attention  between  the  display  screen,  the 
SPA  (to  page  bade)  or  the  binary  display,  and  off-line  documents.  This  pro¬ 
cedure  consumes  time  and  increases  the  likelihood  of  errors.  Converting  binary 
to  octal  provides  an  additional  opportunity  for  error.  Overall  system  effi¬ 
ciency  is  reduced  as  transactions  are  delayed;  the  accuracy  of  the  data  base 
is  reduced  if  errors  are  not  detected;  and  the  system's  contribution  to  mission 
accomplishment  is  diminished. 

Some  TACFIRE  error  messages  are  reasonably  clear  and  specific,  however. 

For  example,  if  a  user/operator  attempts  to  enter  39  as  the  day  of  the  month 
in  the  SYS;INIT  message,  the  error  indication  "DAY  TOO  LARGE  FOR  MONTH"  prob¬ 
ably  will  make  the  nature  of  the  error  clear.  But,  most  error  messages  examined 
appeared  far  more  cryptic.  "AA/AAA  ILLEGAL  MESSAGE  CATEGORY,"  for  example, 
does  not  tell  the  user/operator  clearly  that  a  message  category  was  entered 
that  does  not  match  any  of  the  message  categories  currently  stored  in  the  PCLD 
table.  Also,  the  message  does  not  tell  the  user/ operator  the  location  of  the 
error  in  the  input  message. 

IISS  provides  a  number  of  error  messages  in  the  message  screen  area.  The 
list  of  error  messages  available  during  the  review  of  the  system  includes  a 
number  of  error  and  system  messages  which  are  not  tied  to  user  error  per  se, 
but  which  may  result  from  system  errors  or  programming  errors.  The  available 
documentation  is  unclear  about  whether  such  messages  are  ever  presented  to  the 
USAREUR  analysts  who  use  IISS.  If  they  are  presented,  it  is  not  likely  that 
they  would  be  particularly  meaningful.  The  list  is  apparently  not  comprehensive, 
however,  since  examples  of  processing  contained  in  the  IISS  Data  Base  User's 
Guide  list  error  messages  which  are  not  contained  in  the  list  examined.  In 
addition,  the  information  content  of  the  IISS  error  messages  is  often  quite 
low.  The  IISS  error  messages  are  too  vague  to  permit  users/operators  to  quickly 
grasp  the  precise  error  condition  involved.  Further,  the  stilted  formal  grammar 
and  syntax  of  the  messages  make  it  difficult  for  the  users/operators  to  inter¬ 
pret  the  reference  of  the  messages.  Difficulty  in  interpreting  the  error 
messages  will  increase  the  time  required  for  error  detection  and  subsequent 
error  correction,  and  delivery  of  intelligence  information  to  the  battlefield 
commander  may  be  delayed. 
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No  specific  diagnostic  or  instructional  information  is  provided  on  TCT. 
Invalid  entry  of  data  receives  only  an  "INVALID  ENTRY.  TRY  AGAIN"  message. 

The  user/operator  is  forced  to  determine  why  the  entry  was  invalid  either 
through  short  term  memory — recall  of  which  key  was  pressed — or  long  term 
memory — recall  of  procedural  validity  trees.  Transactions  may  be  delayed 
while  the  user/operator  diagnoses  and  corrects  the  error.  There  is,  further, 
potential  for  operator  confusion  and  additional  unnecessary  system  delay. 

7.4  Error  correction  and  recovery  techniques,  once  errors  have  been 
detected  they  must  be  corrected.  The  systems  examined  offer  a  variety  of 
techniques  for  recovery  from  error  conditions. 

As  noted  above  ,  TACFIRE  error  correction  begins  only  after  the  entire 
message  is  completed  and  entered  for  processing.  For  each  error,  the  user/ 
operator  must  first  diagnose  the  error,  retrieve  the  correct  entry  from  memory 
of  off-line  manuals,  visually  locate  the  data  element  containing  the  error 
and  then  position  the  cursor  to  the  element  field  using  the  cursor  control 
keys.  In  the  event  of  multiple  errors,  this  procedure  must  be  repeated  for 
each  error.  The  procedure  is  unwieldy  and  unnecessarily  complicates  the  user's/ 
operator's  task.  In  some  cases,  a  single  error  may  require  reentry  of  several 
data  element  fields.  For  example,  to  orient  the  DPM,  the  user/operator  enters 
into  the  SPRT;MAP  message  the  coordinates  of  each  of  the  four  corners  of  the 
map.  However,  an  error  at  any  point  in  this  procedure  requires  the  user/ 
operator  to  re-enter  all  four  comers  again,  even  if  three  of  the  four  are 
correct.  This  is  an  unnecessary  source  of  frustration,  imposes  unnecessary 
effort,  and  requires  excessive  time  to  correct  errors.  In  operational  situations, 
delays  in  orienting  the  DPM  will  delay  graphic  presentation  of  artillery  target 
intelligence  and  thereby  delay  artillery  command  and  control  functions.  This 
delay  in  turn  may  result  in  loss  of  important  targets . 

Error  correction  and  recovery  are  handled  quite  well  in  the  Automated  Run 
Book.  The  only  deficiency  noted  in  this  regard  was  observed  in  the  data  reduc¬ 
tion  function.  When  the  user/operator  commits  an  error  during  data  entry  or 
error  correction,  a  message  is  presented  at  the  top  of  the  display.  This  message 
is  not  removed  from  the  scneen  after  the  user  corrects  the  error:  it  remains 
in  place  until  the  current  transaction  is  completed.  This  feature  has  the 
following  disadvantages: 
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a.  If  the  user/operator  sees  the  message,  corrects  the  error,  and 
then  goes  on  to  enter  data  in  subsequent  fields,  he  or  she  may 
look  up,  see  that  same  message,  and  try  to  relate  it  to  the 
current  data  field.  Thus,  the  message  could  be  a  source  of 
difficulty  for  the  user/operator,  and  an  unnecessary  source  of 
frustration  as  well. 

b.  If  the  user/operator  commits  a  subsequent  error,  the  second 
message  merely  overprints  the  first.  If  the  second  message 
is  shorter  than  the  first,  the  remaining  "tail"  of  the  first 
message  could  in  effect  change  the  meaning  of  the  second 
message,  or  render  the  second  message  uninterpretable. 

Once  errors  have  been  detected  in  IISS,  they  can  be  corrected  in  one  of 
two  ways: 

a.  The  screen  area  may  be  cleared,  and  ‘.he  entire  statement 
re-entered. 

b.  The  screen  editor  and  cursor  FFKs  of  the  SU  1652  may  be  used 
to  correct  the  error  in  the  command  or  data  entry  input. 

In  making  error  corrections  for  multi-line  commands  on  IISS,  the  SU  1652  has 
pure  cursor  move  commands  which  allow  the  user/operator  to  copy  information 
already  on  the  screen.  While  copying,  the  user/operator  may  also  make  editing 
changes  to  correct  errors  made  in  the  original  entry  of  the  command  string. 

When  in  GIM-II  Language  mode,  the  user/operator  may  enter  several  lines  of 
commands  before  pressing  the  SEND  key  to  pass  the  commands  to  the  AN/GYQ-21 (V) . 

If  there  is  an  error  in  the  command,  the  user/operator  may  use  the  cursor  to 
recopy  the  command  up  to  the  point  where-  the  error  occurred,  correct  the  error, 
and  then  copy  the  remainder  of  the  command.  It  can  then  be  transmitted  to  the 
central  computer  for  evaluation.  As  IISS  is  currently  structured,  however,  the 
user/operator  must  make  a  change  in  each  line  of  a  multi-line  command,  even 
when  there  is  no  error  in  that  line.  Thus,  the  user/operator  is  forced  to  make 
irrelevant  changes  to  command  lines  to  ensure  eventual  acceptance  of  the  com¬ 
mands  by  the  system  processor.  This  process  wastes  time.  In  addition,  the 
requirement  to  make  at  least  one  change  in  all  lines  of  a  multiple-line  com¬ 
mand  containing  an  error  is  easily  forgotten,  since  the  procedure  is  an  essen¬ 
tially  illogical  one. 

Correction  of  errors  will  take  more  time  them  would  be  required  for  a  better 
designed  error  correction  procedure.  In  addition,  the  probability  of  multiple 
errors  is  increased,  since  the  user/operator  may  forget  the  seemingly  unnecessary 
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Requirement  to  make  changes  in  what  appear  to  be  valid  command  entries.  Inex¬ 
perienced  users/operators  may  not  be  able  to  determine  why  the  system  refuses 
to  accept  seemingly  valid  commands.  Because  of  increased  time  to  correct 
errors  and  the  increased  likelihood  of  multiple  sequential  errors,  intelligence 
information  m=>y  be  delayed  in  reaching  battlefield  commanders. 

8.  User/Operator  Configuration 

In  analyzing  various  battlefield  automated  systems,  the  concept  of  user/ 
operators  had  to  be  restricted  considerably.  In  a  very  important  sense,  the 
commander  is  the  ultimate  user  of  any  battlefield  automated  system,  for  the 
obvious  reason  that  he  is  the  unit's  ultimate  decision-maker  and  has  the  ulti¬ 
mate  responsibility  for  the  unit.  In  another  important  sense,  members  of  the 
commander's  staff  are  primary,  since  they  generally  filter  incoming  informa¬ 
tion  for  the  commander  in  accordance  with  his  guidance.  Additionally,  other 
personnel  receive  and  use  information  generated  by  battlefield  automated  systems. 

An  yet,  many  of  these  individuals  seldom  if  ever  will  interact  with  these 
systems.  Instead,  they  use  the  system  indirectly,  through  subordinate  func¬ 
tional  personnel  who  are  trained  to  serve  as  intermediaries.  Although  this 
practice  may  change  in  the  future  as  increasing  numbers  of  systems  are  deployed 
and  more  personnel  become  familiar  with  them,  it  seems  to  be  the  dominant 
practice  today.  Consequently,  to  limit  the  analysis  to  manageable  bounds, 
attention  was  confined  only  to  personnel  who  actually  interact  with  the  machine 
directly,  or  who  clearly  interact  frequently  with  those  personnel.  Even  so, 
user/operator  configurations  ranged  from  highly  complex  to  very  simple.  TACFIRE 
is  an  example  of  the  former  case. 

In  principle,  possible  user/operator  configurations  in  TACFIRE  are  extrem¬ 
ely  varied.  For  example,  virtually  any  user  or  operator  can  transmit  an  ATI 
message  to  the  computer,  from  which  it  may  go  to  the  intelligence  section  or 
to  one  of  the  support  unit  FSEs.  Perhaps  the  most  common  user/operator  configura¬ 
tion  is  exemplified  by  the  following  series  of  transactions  (see  Figure  36)  . 

The  FO  (a  user)  provides  information  and  instructions  to  the  RTO  (an  operator) . 

The  RTO  transmits  a  fire  request  on  the  DMD.  The  request  is  received  on  the 
ACC  RD  at  the  cannon  battalion  where  the  ACCO  (an  operator)  transmits  it  to 
the  computer.  After  processing,  the  computer  displays  battery  firing  data, 
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any  error  and  warning  messages,  and  if  the  selected  batteries  cannot  provide 
sufficient  fire,  request  for  additional  fire  (RFAF)  messages  directed  to  other 
cannon  battalions  or  to  the  FA  brigade.  These  messages  are  transmitted  auto¬ 
matically  to  the  VFMED  (operated  by  the  fire  support  NCO)  at  the  support  unit's 
FSE ,  where  they  are  reviewed  by  the  FSO  (a  user).  The  FSG  can  cancel  the  fire 
mission,  approve  it  as  computed,  or  modify  any  or  all  parts  of  the  mission. 

If  the  mission  is  modified,  new  firing  data  are  computed  and  presented  on  the 
VFMED  for  review.  When  the  FSO  approves  the  mission,  either  as  originally 
computed  or  as  modified,  the  fire  support  sergeant  presses  a  transmit  switch. 
The  firing  data  are  then  transmitted  automatically  to  the  appropriate  battery 
BDU's,  where  the  battery  executive  officer  (XO — a  user/operator)  relays  them 
to  gun  crews.  RFAF  messages  are  transmitted  automatically  to  the  appropriate 
cannon  battalion  computers,  and  a  message  to  observer  (MTO)  is  transmitted 
automatically  to  the  RTO  who  relays  the  information  to  the  FO. 

Little  information  has  been  available  regarding  TCT  user/operator  con¬ 
figurations.  Clearly,  however,  the  TCT  with  its  two  communication  channels 
will  have  many  fewer  interaction  possibilities  than  will  the  TCS  with  its 
sixteen  channels.  In  a  recent  operational  test,  one  TCT  at  the  level  of  corps 
was  connected  to  two  other  TCTs  at  subordinate  echelons,  providing  a  simple 
tree  structure  arrangement.  Presumably,  this  structure  could  be  extended  as 
desired,  with  each  TCT  at  one  level  connected  to  two  below  it. 

probably,  however,  TCTs  in  general  will  be  connected  to  TCSs  as  the 
system  evolves,  so  that  the  greater  storage  capacity  and  computational  power 
of  the  larger  machine  will  be  available  to  a  larger  user/operator  community. 

In  addition,  the  assumption  seems  reasonable  that  TCSs  will  be  interconnected, 
and  that  some  TCTs  will  gain  access  to  TCSs  through  other,  intermediate,  TCTs. 

If  these  speculations  are  valid,  then  one  can  expect  quite  complex  user/ 
operator  configurations  to  emerge  as  the  system  continues  to  evolve.  Inter¬ 
actions  among  the  members  of  these  configurations,  with  personnel  of  varying 
functional  areas,  grades,  and  skill  levels,  could  well  become  a  source  of 
degradation  in  overall  system  performance.  Thus,  while  little  of  substance 
can  be  said  about  this  topic  at  present,  it  is  one  that  should  be  considered 
carefully  during  planning  for  future  steps  in  system  evolution . 


87 


I 


a.  USAREUR  HQ  GOB  analysts. 

b.  CORPS-level  GOB  analysts. 

c.  Intelligence  Support  Element  (ISE)  personnel. 

d.  IISS  system  operator  personnel. 

e.  G2  command  personnel. 

The  first  three  types  are  essentially  similar.  The  USAREUR  HQ  GOB  analysts 
perform  all  of  the  TACOB  (or  other  GOB  file  updates) ,  while  the  Corps-level 
and  ISE  users  typically  perform  only  retrievals.  Restrictions  on  user 
activity  are  easily  controlled  by  system  personnel,  so  it  is  not  inaccurate 
to  consider  the  first  three  types  as  essentially  identical. 

The  review  did  not  evaluate  the  role  of  the  IISS  system  operator  per¬ 
sonnel.  During  on-site  observations,  these  personnel  were  primarily  support¬ 
ing  the  operations  of  the  analyst-users.  There  was  insufficient  time  to  per¬ 
form  adequate  analyses  of  both  classes  of  "hands-on"  users/operators;  reviewing 
analyst/system  interface  was  selected  as  being  of  higher  priority.  Ignoring 
the  role  of  the  IISS  system  personnel,  there  are  essentially  two  user/operator 
configurations  which  are  important  in  IISS  operations: 

a.  GOB  analysts  operating  autonomously.  There  are  many  tasks 
which  the  GOB  analysts  will  perform  with  little  or  no  super¬ 
vision  from  or  coordination  with  G2  command  personnel.  Most 
of  the  data  base  updates,  for  instance,  can  only  be  performed 
by  the  GOB  analysts  themselves.  A  complete  and  up-to-date 
data  base  is  critical  to  the  overall  utility  of  IISS.  Updat¬ 
ing  it  is  in  essence  a  "background-mode"  operation:  updates 
must  be  performed  when  time  is  available  and  when  critical 
retrievals  are  not  required  by  command  personnel. 

b.  GOB  analysts  operating  under  direct  supervision  of  G2  personnel. 
Particularly  during  crisis  periods  battlefield-echelon  intelli¬ 
gence  officers  will  be  attempting  to  collect,  coordinate,  and 
analyze  intelligence  of  direct  relevance  to  combat  commanders. 

Since  IISS  will  be  a  significant  resource  for  order-of-battle 
information,  it  is  likely  that  intelligence  officers  will  be 
interacting  directly  and  frequently  with  IISS  GOB  operator/ 
analysts. 

The  DAS  3  computer  will  be  operated  by  a  system  operator.  The  operator's 
interactions  with  functional  users  evidently  will  be  minimal,  particularly  in 
regard  to  performing  tasks  related  to  the  Automated  Run  Book  and  DS4. 
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Two  users  will  be  able  to  interact  with  the  Automated  Run  Book  at  a  time, 
one  from  each  user  terminal.  However,  each  will  be  concerned  with  particular 
tasks,  which  will  not  necessarily  be  related  to  each  other.  Therefore,  little 
interaction  can  be  expected  to  occur  between  the  users  during  DS4  operations. 


CONCLUSION 


The  results  presented  above  support  two  conclusions:  (1)  battlefield  auto¬ 
mated  systems  are  highly  variable  on  a  wide  range  of  attributes  related  to  user/ 
operator  transactions;  and  (2)  while  examples  of  good  design  appear  in  some  of  the 
newer  systems,  in  general  battlefield  automated  systems  are  characterized  by 
design  features  that  are  incompatible  with  human  capabilities  and  limitations. 

Differences  Among  Systems 

That  battlefield  automated  systems  should  differ  among  themselves  is  neither 
particularly  surprising,  nor  on  the  face  of  it  especially  profound.  After  all, 
the  systems  analyzed  in  this  project  are  designed  for  different  purposes,  in 
support  of  different  Army  functional  areas,  to  process  different  data  types,  and 
for  sometimes  radically  different  data  processing  tasks.  Thus,  there  is  no 
intrinsic  reason  why  they  all  should  have  identical  characteristics.  Nonetheless, 
many  of  the  features  related  to  human-computer  interaction  differ  without  appar¬ 
ent  justification. 

For  example,  there  is  no  intrinsic  reason  to  use  command  language  to  perform 
a  function  on  one  system,  function  keys  to  perform  the  same  function  on  another 
system,  and  menus  to  perform  that  function  on  still  another  system.  There  is  no 
intrinsic  reason  to  employ  "standard"  keyboards  on  which  the  locations  of  commonly 
used  non-alphabetic  characters  such  as  and  are  located  dif¬ 

ferently  from  one  system  to  the  next.  If,  say,  a  function  key  is  used  to  clear 
the  display  screen,  there  is  no  intrinsic  reason  to  label  that  key  "ERASE"  on 
one  system  and  "CLEAR  SCRN"  on  another  system.  There  is  no  intrinsic  reason, 
either,  to  locate  the  "TAB"  key  in  three  different  places  or  three  different 
systems.  Nor  is  there  any  intrinsic  reason  to  use  a  format  selection  matrix 
on  one  system  to  specify  a  file  or  other  set  of  information  to  work  on,  to  use  a 
menu  for  that  purpose  on  another  system,  and  a  command  language  for  the  same 
purpose  on  a  third  system. 

Differences  such  as  these  pervade  battlefield  automated  systems.  They 
result  from  differing  design  philosophies  on  the  part  of  vendors  and  from  dif¬ 
fering  human-computer  interface  specifications  on  the  part  of  proponents  and 
developers.  As  noted  earlier  in  this  report,  systems  are  developed  largely  in 
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isolation,  with  little  or  no  coordination  or  information  exchange  among  develop¬ 
ment  projects.  Thus,  lessors  learned  from  one  system  seldom  are  passed  on  to 
new  systems,  and  problems  encountered  in  the  past  must  be  solved  anew  in  the 
present  or  future. 

The  differences  among  systems  have  several  consequences.  For  example, 
stocks  of  spare  parts  must  be  maintained  for  all  the  different  machines  employed 
in  the  diverse  systems.  In  addition,  maintenance  personnel  must  be  trained  or 
retrained  each  time  a  new  system  is  introduced.  More  importantly  from  the  point 
of  view  of  this  project  is  the  iirpact  of  system  differences  on  user/operator 
personnel.  These  differences  might  not  be  important  to  this  group  if  they  were 
assigned  to  one  particular  component  of  one  particular  system  and  then  remained 
there  throughout  their  Army  careers.  But  soldiers  do  not  stay  in  one  place 
throughout  their  careers.  They  move  from  post  to  post,  from  echelon  to  echelon, 
from  duty  assignment  to  duty  assignment — and  increasingly  from  battlefield 
automated  system  to  battlefield  automated  system.  And  each  time  they  encounter 
a  new  system,  they  also  encounter  a  whole  new  learning  experience. 

Part  of  that  new  experience  is  unavoidable,  of  course;  the  user/operator 
necessarily  must  learn  those  functions  and  procedures  that  are  unique  to  the 
new  system.  Even  so,  much  of  the  new  learning  is  avoidable--or  could  be.  For 
the  newly-assiqned  user/operator  must  learn  to  recognize  and  use,  among  other 
differences : 

a.  New  locations  and  labels  for  function  keys. 

b.  New  meanings,  uses,  and  locations  for  special  character  keys. 

c.  New  display  formats. 

d.  New  terminology  for  familiar  objects  or  concepts. 

e.  New  procedures  for  performing  familiar  data  processing  tasks. 

These  and  other  differences  combine  to  make  each  new  system  a  unique 
experience  for  the  user/operator.  They  thus  impose  a  necessity  for  training 
which  contributes  nothing  to  developing  greater  expertise  in  the  functional 
area,  but  merely  contributes  to  making  a  functional  area  soldier  a  better  com¬ 
puter  operator.  Ironically,  it  is  the  skilled,  experienced  individual  who  is 
most  adversely  affected.  Whereas  experience  ordinarily  leads  to  improved 
performance,  in  such  situations  it  can  actually  lead  to  degraded  performance 
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for  some  non-trivial  period  of  time.  For  the  experienced  user /operator  must  not 
merely  learn  the  skills  required  by  the  "new"  system,  but  also  unlearn  the  skills 
that  produced  effective  performance  on  the  "old"  system. 

Human-Computer  Incompatibil ities 

Examples  of  human-computer  incompatibilities  emerged  in  abundance  from  the 
analysis  of  systems  described  above.  These  examples  ranged  from  a  set  of  mes¬ 
sage  format  and  data  field  labels  so  extensive  that  the  user's  manual  required 
ten  volumes,  to  a  command  language  set  so  complex  that  the  system's  users/oper- 
ators  were  not  even  aware  of  the  scope  of  its  capabilities,  much  less  able  to 
use  those  capabilities  to  maximum  effectiveness.  Most  of  the  deficiencies 
observed  during  the  analysis  were  not  so  dramatic  as  these,  of  course,  nor  so 
pernicious.  Considered  individually,  most  deficiencies  were  minor;  many  were 
even  trivial.  Viewed  in  isolation,  most  seem  hardly  worthy  of  mention,  much 
less  any  great  effort  or  expense  to  rectify.  But  viewing  these  deficiencies 
in  isolation  is  most  assuredly  the  wrong  way  to  view  them. 

For  the  fact  is  that,  while  a  proponent,  developer,  or  design  engineer  may 
view  deficiencies  in  the  human-computer  interface  individually,  the  user/operator 
is  not  permitted  that  luxury.  In  practice,  during  system  operations,  design 
deficiencies  appear  rapidly  in  sequence  or  even  simultaneously.  For  example,  an 
individual  may  commit  an  error  because  of  inadequate  information  about  legal 
entries,  encounter  a  mysteriously  coded  error  message  that  provides  little  mean¬ 
ingly  diagnostic  information  once  decoded,  and  then  be  forced  into  a  confusing 
recovery  routine.  In  such  cases,  design  deficiencies  become  something  more  than 
unimportant  idiosyncracies  of  the  system;  they  become  significant  obstacles  to 
smooth,  efficient,  productive  performance.  If  enough  of  these  deficiencies  make 
themselves  felt  at  one  time,  they  may  literally  overwhelm  the  user/operator, 
particularly  during  periods  of  stress. 

These  cumulative  effects  of  otherwise  minor  or  even  trivial  design  deficien¬ 
cies  impose  excessive  demands  on  human  perception,  memory,  intellectual  processes, 
and  in  some  cases  perhaps  even  motor  capabilities.  As  a  consequence,  many  battle¬ 
field  automated  systems  demand  higher  skill  levels  than  anticipated  by  their 
developers.  In  addition,  as  with  differences  between  systems,  time  and  effort 
must  be  devoted  to  learning  a  system's  peculiarities  that  would  be  better  spent 
in  developing  greater  expertise  in  the  functional  area  of  system  supports. 
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Once  again,  most  of  this  training  does  nothing  to  develop  a  better-qualified 
functional  area  soldier,  but  instead  goes  to  develop  a  better  computer  operator. 

At  an  In  Progress  Review  midway  through  the  first  phase  of  this  project, 
the  speaker  reviewed  early  results  from  the  analysis  of  battlefield  automated 
systems.  He  outlined  the  consequences  of  differences  among  systems  and  of  design 
features  incompatible  with  human  characteristics  as  discussed  above.  Then,  he 
posed  the  following  questions,  only  half  humorously. 

Vino  are  the  villains? 

Who  gets  beamed? 

Whose  backside  gets  kicked? 

Whose  name  gets  taken? 

The  speaker  concluded  that  in  reality  there  are  no  villains.  He  argued  that 
system  proponents  are  eager  to  specify  rational,  meaningful  user  requirements. 

He  suggested  that  developers  ara  more  than  willing  to  meet  the  requirements 
stated  by  proponents.  He  maintained  that  vendors  are  anxious  to  meet  the  design 
specifications  written  by  developers.  The  problem,  he  claimed,  is  the  process , 
not  the  people . 

That  is ,  proponents  lack  the  tools  to  describe  user  requirements  with  clarity 
and  precision.  Developers  lack  the  tools  to  translate  user  requirements  into 
specific,  detailed  design  specifications.  Vendors  lack  the  tools  to  convert 
design  specifications  into  properly  designed  and  engineered  human-computer  inter¬ 
face  hardware  and  software.  As  a  consequence,  the  user/operator  encounters  a 
system  which  may  well  be  optimal  from  economic,  engineering,  and  programming 
points  of  view.  Too  often,  however,  the  system  is  anything  but  optimal  from  the 
user's/operator's  point  of  view. 

The  fundamental  problem,  then,  is  that  today  there  is  no  adequate  human 
factors  technology  for  the  design  of  user/operator  transactions  that  is  readily 
available  to  the  people  who  specify ,  develop,  and  build  battlefield  automated 
systems.  A  major  goal  of  this  project  is  to  begin  development  of  that  technology. 

Results  of  the  initial  phase  of  this  project  suggest  conclusions  concerning 
design  guidelines  and  evaluation  criteria  in  the  following  five  main  areas: 

1.  Relationship  of  guidelines  and  criteria  to  Transaction  Fea¬ 
ture  Analysis. 

2.  Differentiation  of  guidelines  and  criteria. 
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3.  Relationship  of  criteria  to  the  body  of  behavioral  know¬ 
ledge  and  methodology. 

4.  The  differentiated  state  of  knowledge  concerning  the  cri- 
terial  sub-domains  of  speed  and  accuracy. 

5.  The  potential  synergistic  impact  of  simultaneous  presentation 
of  guidelines  and  criteria. 

Transaction  Feature  Analysis 

Considerations  of  evaluation  criteria  are  pervasive  and  inherent  in  any 
effort  to  identify  and  assess  the  qualities  of  design  features.  The  relevance 
and  effectiveness  of  these  features  are  almost  always  judged  on  the  basis  of 
their  apparent  impact  on  transaction  speed  and/or  accuracy.  Consequently, 
delineations  of  both  design  guidelines  and  criteria  derive  rather  directly  from 
transactional  feature  analysis. 

Criteria  Versus  Guidelines 

The  concepts  of  design  guidelines  and  of  evaluation  criteria  are  neither 
simple  nor  undimens ional.  Further,  their  differentiation  is  complicated  by 
intimate  functional  relationships.  In  general: 

1.  Design  guidelines: 

a.  Imply  what  to  design  into  the  system. 

b.  How  to  accomplish  effective  design. 

2.  Evaluation  criteria: 

a.  Imply  what  to  evaluate  about  observed  or  anticipated 
transaction  performance. 

b.  Suggest  why  transaction  design  effort  is  worth  effort. 

Behavioral  Knowledge  and  Methods 

Criteria  derive  relatively  productively  from  a  conventional  behavioral 
framework  (e.g.,  perception,  memory,  intellectual  processing,  action,  feed¬ 
back)  imposed  on  each  principal  area  of  transaction  design.  Consequently, 
the  structure  of  extant  behavioral  research  results  should  be  consistent  with 
requirements  for  criterial  data  Also,  productive  new  research  should  be 
achievable  using  relatively  conventional  methods.  The  problem  is  to  bound 
the  behavioral  context  by  the  same  constraints  that  will  bound  design  deci¬ 
sions  and  system  testing. 
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Speed  Versus  Accuracy 


The  criteria  domain  must  simultaneously  deal  with  the  sub-domains  of 
performance  speed  and  accuracy.  This  simultaneity  requirement  is  driven  by: 

1.  Tradeoffs  between  the  two  domains. 

2.  Regions  of  joint  optima  which  shift  from  one  transaction  cate¬ 
gory  to  another. 

The  criterial  domain  is  further  complicated,  currently,  by  differing  amen¬ 
ability  of  the  two  sub-domains  to  behavioral  differentiation.  That  is,  in 
general : 

1.  Existing  data,  behavioral  models,  and  research  methods  permit 
productive  differentiation  of  errors  by  behavioral  categories. 

2.  Current  data,  beha\ioral  models,  and  research  methods  do  not 
permit  very  cost  effective  partitioning  of  total  transaction 
time  into  behavioral  conponents. 

Guideline  and  Criterion  Presentation 

We  can  see  productive  synergism  deriving  from  simultaneous  presentation 
of  guideline  and  criterion  information.  This  is  because  such  simultaneous 
information  presentation  would  permit  the  designer  to  consider  as  a  coherent 
set: 

1.  The  principal  design  alternatives  currently  available. 

2.  The  probable  impact  of  alternative  design  routes. 

3.  The  nature  of  performance  tradeoffs  implied  by  different 
design  alternatives. 

Structure  of  Provisional  Guidelines  and  Criteria 

Information  about  the  problems  and  deficiencies  in  the  human-computer 
interface  provided  a  "real  world"  orientation  for  the  development  of  guide¬ 
lines  and  criteria.  This  orientation,  coupled  with  considerations  outlined 
above,  determined  the  essential  characteristics  of  design  guidelines  and 
criteria.  Then,  following  the  format  of  Table  4  in  this  document,  these 
characteristics  were  described  in  terms  of  each  category  and  subcategory 
listed  in  the  table.  These  descriptions  indicate  the  direction  of  further 
guideline  and  criteria  development  for  the  prototype  handbook  that  will  be 
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produced  during  the  project's  second  phase.  For  each  subcategory  listed  in 
the  table,  discussions  were  organized  in  four  topical  areas: 

1.  AREAS  OF  APPLICATION:  suggests  the  situations  in  which  design 
methods  in  the  category  might  be  applied. 

2.  METHODS:  lists  the  specific  design  methods  which  might  be 
used  to  provide  the  interactive  capabilities  implied  by  the 
category  title. 

3.  FACTORS  INFLUENCING  APPLICABILITY:  identifies  conditions  and 
situations  which  affect  the  selection  of  particular  design 
methods . 

4.  CRITERION  AREAS:  describe  the  ways  in  which  design  methods 
would  affect  user/operating  performance  in  interacting  with 
Army  battlefield  automated  systems. 

In  addition,  three  sets  of  provisional  guidelines  were  generated  to  exem¬ 
plify  the  prototype  handbook: 

1.  Areas  1.1  through  1.4:  Command  Methods  for  Alphanumeric 
Terminals. 

2.  Area  2.4:  Selective  Highlighting. 

3.  Area  3.1:  Information  on  Legal  Entries. 

These  guideline  sets  are  organized  as  follows: 

1.  DEFINITION:  specifies  the  role  of  the  design  feature  in 
human-computer  interaction. 

2.  USE:  indicates  why  a  design  feature  in  the  category  might 
be  used  to  enhance  user/operator  performance  with  battle¬ 
field  automated  systems. 

3.  APPLICATIONS:  describes  some  of  the  important  situations 
in  which  the  design  feature  might  be  employed.  Each  appli¬ 
cation  description  includes  an  example  of  processes  which 
might  be  encountered  in  Army  battlefield  automated  systems. 

4.  TYPES:  describes  the  ways  in  which  particular  design  methods 
might  be  applied  to  user/operator  interaction  with  Army 
battlefield  automated  systems.  Where  appropriate,  examples 
of  these  design  methods  are  provided.  The  examples  reflect 
implementations  which  might  actually  appear  in  battlefield 
automated  systems. 

5.  RECOMMENDATIONS :  presents  recommendations  for  the  situations 
in  which  design  methods  should  be  employed  in  particular  appli¬ 
cation  areas.  Recommendations  are  presented  in  tables  which 
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rate  methods  with  respect  to  their  general  utility  in  the 
applications  listed. 

6.  ADVISORY  COMMENTS:  discuss  special  factors  which  affect  the 
utility  of  particular  design  methods  in  particular  applica¬ 
tions  or  under  special  circumstances.  Environmental,  system 
hardware,  system  software,  and  other  factors  which  might 
influence  the  success  of  the  implementation  of  the  method 
are  discussed. 

Volume  IV  of  this  report  presents  these  materials  in  detail.  Therefore, 
they  are  not  discussed  further  in  this  volume. 


PROBLEMS  AND  DEFICIENCIES 

The  nature  of  the  problems  and  deficiencies  in  battlefield  automated 
systems  became  apparent  during  the  analysis  described  above.  As  noted 
earlier,  the  fundamental  problem  is  the  lack  of  an  adequate  human  factors 
technology  for  the  design  of  user/operator  transactions.  This  leads  to 
poor  design  within  systems  from  the  user' s/ opera tor* s  point  of  view  and  to 
unnecessary  differences  in  functionally  similar  design  features  from  one 
system  to  another.  The  result  is  a  need  for  unnecessarily  stringent  skill 
requirements  and  for  unnecessarily  extensive  training  merely  to  make  a  com¬ 
puter  operator  of  a  functional  person. 

The  nature  of  the  problems  and  deficiencies  in  the  human  factors  tech¬ 
nology  became  apparent  during  preparation  of  the  provisional  guidelines  and 
criteria  described  briefly  above  and  presented  in  greater  detail  in  Volume 
IV.  Where  possible,  guidelines  were  developed  on  the  basis  of  published 
research  results.  The  literature  containing  these  results  is  summarized  in 
Volume  V  of  this  report.  Where  the  published  research  failed  to  resolve  an 
issue — or  failed  even  to  address  an  issue — the  guidelines  and  criteria  were 
based  on  the  best  judgments  of  personnel  experienced  in  the  human  factors  of 
interface  design.  Unfortunately,  best  judgment  was  used  far  more  often 
than  research  results.  As  an  example  of  the  inadequacies  of  the  literature 
from  this  project's  viewpoint,  consider  the  following  discussion  of  user/ 
operator  configurations  (topic  number  8  in  Table  4). 

Assuring  success  in  the  design  and  use  of  battlefield  automated  systems 
depends  heavily  upon  knowledge  about  a  system's  user/operator  configuration 
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as  well  as  its  human-machine  interface.  A  major  obstacle  to  focusing  atten¬ 
tion  successfully  on  the  user/operator  configuration  is  the  general  lack  of 
fundamental  information  about  behaviors  associated  with  the  interface.  The 
Army,  and  the  military  establishment  in  general,  have  explored  team  training 
and  team  performance  (frequently  referred  to  as  "crew"  training  and  perform¬ 
ance)  in  many  ways  and  under  many  conditions.  Despite  these  efforts,  little 
is  known  about  the  personal  dynamics  of  team  performance.  Even  if  these  team 
situations  were  fully  understood,  there  are  enough  differences  between  them 
and  typical  battlefield  automated  information  systems  situations  to  warrant 
the  data  considerably  less  than  fully  applicable.  Some  of  these  differences 


a.  Most  team  training  performance  investigations  have  centered 
on  situations  related  to  a  physical  output,  e.g. ,  firing  a 
missile  or  maneuvering  a  tank.  Battlefield  automated  systems 
may  indeed  support  these  same  missions,  but  the  typical  user/ 
operator  will  be  more  remote  from  the  scene.  There  may  be 

no  product  available  to  the  user/operator  other  than  a  perish¬ 
able  screen  image. 

b.  The  battlefield  automated  system  "team"  very  often  will  not 
be  colocated;  interactions,  even  crucial  interactions,  fre¬ 
quently  will  occur  between  total  strangers  rather  than 
between  people  who  have  trained,  worked,  and  played  together. 

c.  The  BAS  user/operator  probably  develops  a  more  "kindred" 
feeling  toward  the  computer  than  does  the  ordinary  instru¬ 
ment  user  about  those  instruments.  Ifte  fluidity  of  the 
system  tends  to  generate  such  a  "personal"  relationship. 

Some  systems  even  promote  a  kind  of  identification  with  the 
system.  The  Automated  Run  Book's  master  menu  display,  for 
example,  begins  with,  "Hello!  I  am  DS4  and  I  am  ready..." 
with  the  "I"  referring  to  the  system. 

d.  Menus  and  commands  place  the  user/operator  in  the  situation 
of  carrying  on  a  dialogue  with  an  inanimate  object.  In 
addition,  anthropomorphism  such  as  described  above  may 
cause  negative  reactions  on  the  part  of  some  users/operators. 

To  provide  guidelines  and  criteria  applicable  to  the  user/operator  con¬ 
figuration  found  in  battlefield  automated  systems,  answers  are  required  to 
questions  such  as  the  following: 

a.  What  are  the  performance  effects  of  colocated  users/operators 
who  can  communicate  directly  with  each  other,  versus  those 
who  arc  separated  physically  and  only  communicate  electroni¬ 
cally  through  radio,  telephone,  or  screen  images? 
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b.  How  do  the  tasks  and  behaviors  of  functional  personnel  in 
the  battlefield  automated  system  differ  from  those  of  func¬ 
tional  personnel  in  the  corresponding  manual  systems? 

c.  How  do  group  dynamics  differ  between  colocated  and  separated 
users/operators  in  a  system? 

d.  Are  different  types  of  human-computer  interaction  (e.g. ,  com¬ 
mand  language,  menu,  fill-in-the-blanks)  appropriate  for  dif¬ 
ferent  types  of  users/operators  (e.g.,  personality,  experience)? 

e.  How  "friendly"  should  a  computer  be  to  its  users/operators  (e.g, 
"Hello!  I  am  DS4  and..."  versus  "Please  choose  what  you  want 
to  do  from  the  following  menu"  versus  "Enter  menu  selection")? 

f.  Are  user-user  interactions  as  important  to  overall  system 
performance  as  user-computer  interactions? 

Questions  such  as  the  above  arise  in  every  category  listed  in  Table  4. 

Other  questions  of  a  more  general  nature  also  arise.  For  example,  in  what 
ways  do  individual  design  deficiencies  accumulate  to  degrade  user/operator 
performance?  Which  combinations  of  deficiencies  are  most  harmful  to  effective 
performance?  What  are  the  effects  of  design  deficiencies  on  user  acceptance 
of  the  system?  On  user/operator  morale?  Which  types  of  deficiencies  have 
have  the  greatest  impact  on  performance?  On  user  acceptance?  On  morale? 

Guidelines  and  criteria  can  be  developed  on  the  basis  of  expert  judg¬ 
ment,  at  least  initially.  These  prototype  guidelines  and  criteria  will  have 
served  a  useful  purpose  even  if  they  are  not  all-inclusive  and  not  entirely 
correct  and  accurate — if  they  encourage  a  measure  of  consistency  in  the  design 
of  user/operator  transactions.  They  will  have  served  an  equally  useful  pur¬ 
pose  if  they  generate  controversy  in  the  academic  human  factors  community. 

For  if  that  controversy  arises,  then  perhaps  researchers  will  undertake 
controlled  experimental  investigations  of  the  guidelines.  Those  investiga¬ 
tions  would  provide  substantial  benefit  to  proponents,  developers,  and  builders. 
Because,  while  the  crucible  of  real  world  system  development  ultimately  will 
refine  and  validate  guidelines — and  indeed  must  of  necessity  provide  the  ulti¬ 
mate  refinement  and  validation — a  systematic,  guideline/criteria-oriented 
program  of  research  would  accelerate  this  effort  tremendously. 
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APPENDIX  A 


TYPES  AND  AMOUNTS  OF  INFORMATION 
OBTAINED  FROM  REVIEWS  OF  BAMP 
SYSTEM  SYNOPSES 


■  EISOE 


■  E3SDH 


Key 


«  N/A 

«  No  Information 
■  Reference,  but  no  substance 
3  Useful  but  incomplete  data 
*  Complete  Information 

INFORMATION  TYPE 

Frequency _ 

SYSTEM  OUTPUTS _ 

0  Type  of  Information _ 

0  Users  of  Information _ 

0  Required  Characteristics  of  Information 
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APPENDIX  C 


SAMPLES  OF  BRIEF  REPORTS  PREPARED 
DURING  SURVEY  OF  ARMY 
BATTLEFIELD  AUTOMATED  SYSTEMS 
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DLDED — Di vision  Level  Data  Entry  Device 


DLDED — THE  DIVISION  LEVEL  DATA  ENTRY  DEVICE 


PURPOSE  AND  MAJOR  FUNCTIONS 

At  present,  personnel  administration  and  logistics  input  to  the  Army 
division’s  Combat  Service  Support  System  (CS3)  depends  on  punched  cards. 

The  Division  Level  Data  Entry  Device  (DLDED) ^  will  replace  the  punched  card 
method  with  an  ADP  data  entry  system,  to  reduce  both  error  rates  and  turn¬ 
around  time.  Intended  as  the  standard  data  entry  system  for  supply,  main¬ 
tenance,  and  personnel  administration  operations  of  the  division,  the  DLDED 

2 

will  support  the  following  user  functions: 

a.  Data  entry. 

b.  File  processing. 

c.  Data  communication. 

d.  Report  generation. 

e.  Inquiry /retrieval  from  files. 

f.  Text  editing. 

g.  Arithmetic  calculation. 

h.  Data  display  and  manipulation. 

i.  Prompting. 

These  functions  encompass  virtually  all  user/operator  transactions  with 
admin/log  ADP  systems,  all  of  which  employ  punched  card,  batch-processing 
methods.  Therefore,  the  following  description  constitutes  a  preliminary 
human  factors  analysis  for  all  those  systems,  since  the  DLDED  will  provide 
user/operator  input  for  every  one  of  them. 

^ DIDED — Division  Level  Data  Entry  Device.  Functional  System  Requirement . 
U.S.  Army  Administration  Center,  Systems  Design  Directorate,  Fort  Benjamin 
Harrison,  Indiana,  undated. 

2/ 

Letter  of  Inquiry  (LOI)  For  the  Division  Level  Data  Entry  Device.  Project 
Management  Office,  Tactical  Management  Information  Systems,  Fort  Belvoir, 
Virginia,  15  Dec  1979. 
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RELEVANT  HARDWARE  ELEMENTS 


The  DLDED  will  be  a  subsystem  of  the  division  CS3,  in  practice.  A 
typical  infantry  division  will  have  54  systems,  allocated  as  follows: 

a.  17  combat  battalions,  1  each. 

b.  17  combat  support,  combat  service  support,  and  headquarters 
units,  1  each. 

c.  Personnel  Service  Division  of  the  Military  Personnel  Office 
(MILPO)  at  the  division's  AG  Company,  8  each. 

d.  Division  Finance  Company,  12  each. 

Specific  hardware  elements  have  not  yet  been  selected,  according  to 
documents  currently  in  Synectics'  possession  as  of  12  May  1980.  Nonethe¬ 
less,  the  Letter  of  Inquiry  cited  above  specifies  that  the  DLDED  will  be 
configured  from  off-the-shelf  equipment,  to  include  the  following  major 
components: 

a.  Computer,  including  CPU,  memory,  clock,  controller's  control 
panel,  and  bus. 

b.  Direct  Access  Storage  (DAS). 

c.  Keyboard  Visual  Display  Unit  (KVDU) . 

d.  Hard-copy  printer. 

e.  Magnetic  storage  device  with  portable  magnetic  medium. 

f.  Communications  capability. 

g.  Power  subsystem. 

h.  Capability  to  add: 

1.  Up  to  3  KVDU  per  DLDED. 

2.  9-track  magnetic  tape  unit  (for  CS3  interface). 

3.  A  Deutches  Bundespost-approved  modem. 

The  Keyboard  Visual  Display  Unit  (KVDU)  is  the  device  of  greatest  con¬ 
cern  to  this  contract.  The  Letter  of  Inquiry  specifies  that  the  display 
screen  shall  display  a  minimum  of  24  lines,  with  a  minimum  of  80  characters 
per  line.  The  display  character  set  shall  consist  of  the  64-character  ASCII 
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subset  at  a  minimum,  with  zero  distinguishable  from  alphabetic  "0"  and  dis¬ 
played  characters  identical  to  their  keyboard  counterparts.  In  addition, 
the  KVDU  must  have  the  following  characteristics: 

a.  Internal  storage  for  one  complete  screen  of  characters. 

b.  A  programmable  cursor. 

c.  Format  control  by  field,  to  include  tab  and  field  protect. 

d.  Character  and  line  delete  features. 

e.  Line  and  page  erase  of  unprotected  characters,  to  be  replaced 
with  blanks . 

f.  User/operator  response  to  computer-generated  request  for  cursor 
position. 

g.  Program  selectable  transmission  of  protected  or  unprotected 
data  fields. 

h.  Attention  devices  such  as  blinking,  under  software  control. 

i.  The  keyboard  must  contain  at  a  minimum  the  standard  44-key 
QWERTY  format  plus  a  separate  10-key  calculator  keypad. 

j.  Control  keys  for  the  cursor,  to  include  right,  left,  up,  down, 
home  (move  cursor  to  upper  left  corner) ,  and  clear  screen 
(homing  cursor  after  screen  is  cleared) . 

k.  Keys  for  line  feed,  carriage  return,  print,  and  transmit. 

l.  Wraparound  (last  character  of  a  line  to  first  character  of  the 
next  line  down,  and  from  first  character  of  a  line  to  last 
character  of  the  next  line  up) . 

m.  At  least  10  function  keys  separate  from  the  alphanumeric  keys. 

USER/OPERATOR  CONFIGURATIONS 

User/operator  configurations  are  extremely  simple  in  the  DLDED.  As 
noted  previously,  54  systems  will  be  installed  in  the  typical  infantry 
division,  functioning  as  subsystems  in  the  division's  CS3.  However,  avail¬ 
able  documentation  suggests  that  these  will  not  interact  with  each  other. 

As  described  in  the  functional  system  requirement  document  (Note  1  above), 
data  originate  at  the  company  level  and  are  sent  to  battalion  as  hard-copy. 
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DIDED  users/operators  at  battalion  will  transcribe  the  data  at  the  KVDU.  The 
input  device  will  be  an  intelligent  terminal.  At  battalion,  it  will  provide 
extensive  tutorials  and  prompts,  plus  limited  editing  capabilities,  so  that 
users/operators  will  not  require  lengthy  training  either  in  admin/log  func¬ 
tions  or  in  operating  the  terminal.  The  system  will  format  these  data  into 
files  and  then  write  the  files  onto  a  9-track  output  tape.  The  tape  from 
each  battalion  will  be  delivered  to  division-level  units  (DMMC  for  logistics- 
AG  company  for  personnel).  At  the  division-level,  the  tapes  will  be  pro¬ 
cessed  by  clerks  who  are  trained  in  the  personnel  administration  or  logistics 
functions;  the  DIDED  therefore  will  have  fewer  tutorial  and  prompting  capa¬ 
bilities  and  greater  editing  capabilities  to  permit  manipulation  of  the  data. 
The  division-level  admin/log  clerks  will  merge  tapes  from  lower  units, 
generating  an  output  tape  for  each  major  function  in  CS3  (personnel,  supply, 
and  maintenance.)  These  tapes  will  be  delivered  to  the  Division  Data  Center 
(DDC),  where  they  will  become  inputs  to  CS3.  The  data  flow  described  here 
is  summarized  in  Figure  9,  which  portrays  only  the  data  flow  for  the  Standard 
Installation/Division  Personnel  System  (SIDPERS) ,  but  is  typical  of  logis¬ 
tics  data  flows  as  well. 

At  least  two  DLDEDs  will  be  used  as  data  flows  up  from  the  company  to 
CS3,  one  at  battalion  and  one  at  division.  However,  there  appears  to  be  no 
interaction  between  the  two;  one  provides  input  to  the  other  in  a  kind  of 
sequential  batch-processing  mode.  Therefore,  the  best  characterization  of 
user/operator  configurations  in  the  DLDED  evidently  is  that  of  a  single  user/ 
operator,  interacting  with  his  or  her  own  terminal. 


DESIGN  FEATURES 

Because  hardware  elements  have  not  yet  been  selected  for  the  DLDED  and 
software  programming  has  not  yet  begun,  little  can  be  said  about  the  system’s 
design  features.  Even  so,  the  available  documentation  suggests  that  there 
are  aspects  of  the  DIDED  which  afford  greater  than  average  facility  or  ver¬ 
satility  for  a  system  of  this  type.  Some  examples  of  these  capabilities 
include: 


a.  The  DLDED  executive  system  allows  for  concurrent  execution 
of  and  communication  between  two  or  more  programs/tasks. 

It  also  provides  techniques  for  executing  programs/tasks 
that  exceed  available  main  memory. 
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Figure  9  .  Data  Flow  for  SIDPERS  Supported  by  DLDED. 

(Reproduced  from  functional  requirements 
document — see  Note  1  in  text.) 
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Figure  9.  (Continued) 


C-9 


-  —  - 


b.  An  on-line  HELP  facility  provides  information  and  guidance 
on  the  use  of  programs,  system  utilities,  and  user  command 
and  system  message  interpretation. 

c.  Edit  and  validation  checks  are  established  for  a  wide 
variety  of  formats  and  content. 

d.  Utility  services  are  available  through  a  program  object 
library  and  executed  from  either  the  console  or  an  appli¬ 
cations  program.  These  services  include:  routines  for 
converting  encoded  data  from  one  character  set  to  another; 
a  Core  Dump  for  listing  the  content  of  main  memory;  a 
Panic  Dump  for  listing  the  contents  of  selected  areas  of 
main  memory;  media  to  media  routines;  a  Patch  facility 
for  entering  interim  modifications  to  operational  and 
applications  software;  a  facility  for  creating  and  using 
ad  hoc,  one-time  report  formats;  and  a  facile  soft/merge 
records  capability. 
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IISS — INTELLIGENCE  INFORMATION  SUBSYSTEM 
FIRST  MILESTONE  SYSTEM  (FMS) 


PURPOSE  AND  MAJOR  FUNCTIONS 

"The  IISS  FMS1  is  an  all-source,  mobile,  tactical  intelligence  data  handl- 
2 

ing  system."  In  part  derived  from  the  Army  System  for  Standard  Intelligence 
Terminals  (ASSIST),  the  FMS  is  an  independent  subsystem  of  the  U.S.  Army 
Europe  (USAREUR)  Command  and  Control  Information  System  (CCIS) .  It  extends 
the  information  processing  and  intelligence  disseminating  capabilities  cur¬ 
rently  provided  by  the  U.S.  European  Command's  Analyst's  Information  Display 
and  Exploitation  System  (EUCOM  AIDES)  and  by  ASSIST.  Indeed,  TRW  provides  a 
software  package  that  upgrades  ASSIST  to  roughly  the  same  capabilities  as  the 
FMS. 

The  major  purpose  of  the  FMS  is  to  assist  intelligence  analyst  users  to 
provide  accurate  and  timely  tactical  intelligence  to  commanders  in  Army  Corps 
and  subordinate  echelons  of  USAREUR,  down  to  the  division  or  separate  brigade 
level.  Its  primary  functions3  are: 

1.  On-line  ADP  support  to  intelligence  analysts. 

2.  Access  to  multiple  intelligence  data  bases  through  remote  ter¬ 
minals  and  interconnected  facilities. 

3.  Machine-aided  sanitization  of  intelligence  for  release  to 
collateral  systems. 

4.  Acceptance  of  products  from  tactical  collection  systems. 

5.  Processing  of  ELINT  data. 


1/  2  7 

Also  referred  to  in  some  quarters  as  "I  S',  and  in  the  TRW  documentation 

more  simply  as  "FMS". 

2/ 

Hardware  Operations  Manual  for  Intelligence  Information  Subsystem  (IISS) 
First  Milestone  System  (FMS).  TRW  Defense  and  Space  Systems  Group,  Docu¬ 
ment  No.  28503-W104-RU-00,  6  June  1979,  page  1. 

3//,Ihese  functions  are  derived  from  the  FMS  Hardware  Operations  Manual  (see 
Note  2  above)  and  from  IISS  Users  Manual.  TRW  Defense  and  Space  Systems 
Group,  Document  No.  28503-W094-RU-00>  10  May  1979. 
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6.  Processing  of  data  base  files  on  records  extracted  from  the 
EUCOM  AIDES  Integrated  Data  Base  (IDB)  and  the  USAREUR 
Integrated  Ground  Order-of-Battle  System  (IGOBS)  data  base. 

7.  Dissemination  of  user-to-user  message  traffic  in  FMS  and 
upgraded  ASSIST. 

8.  Access  to: 

a.  FMS  Tactical  Order-of-Battle  (TACOB)  data  base. 

b.  FMS  Training  data  base. 

c.  ASSIST  Locally  Developed  Files  data  base. 

d.  EUCOM  AIDES  IDB  (through  time  sharing  and  remote  job 
entry) . 


RELEVANT  HARDWARE  ELEMENTS 

IISS's  hardware  elements  are  contained  in  three  truck-mounted  complexes: 
a  Mobile  Intelligence  Center  (MIC)  and  two  Mobile  Remote  Intelligence  Ter¬ 
minals  (MRITs) . 


Mobile  Intelligence  Center 

The  MIC  provides  the  primary  FMS  data  base  and  a  master  control  terminal 
for  the  system.  Through  the  Intelligence  Data  Handling  System  Communciations  II 
(IDHSC-II )  network,  AUTODIN,  and  local  facilities,  the  MIC  also  serves  as  the 
primary  communication  center  for  the  FMS,  linking  the  MIC  and  MRITs  to  each 
other  and  to: 

1.  Tactical  collection  system  inputs. 

2.  EUCOM  AIDES. 

3.  National  files  and  the  DoD  Intelligence  Information  System  (DODIIS). 

Each  MIC  contains,  among  other  equipment,  an  AN/GYQ-12 (V)  computer  with 
a  1.128-Mbyte  memory,  five  67-Mbyte  disk  drives,  three  nine-track  tape 
drives,  a  high  speed  impact  line  printer,  one  analyst  terminal,  one  computer 
terminal,  an  AUTODIN  interface  terminal,  and  high  security  communications 
equipment.  The  MIC,  as  shown  in  Figure  1,  is  housed  in  three  truck -mounted, 
radio  frequency  interference  (RFI)  shielded  shelters. 
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Figure  1.  The  FMS  Mobile  Intelligence  Center  (MIC) 
Reproduced  from  IISS  Intelligence  Infor- 
PMtion  Subsystem  for  USAREUR .  TRW  pam¬ 
phlet,  1978. 


Mobile  Remote  Intelligence  Terminal 


The  MRIT  provides  work  stations  for  either  three  or  seven  intelligence 
analyst  users,  depending  on  configuration.  Figure  2  shows  a  seven-position, 
large  MRIT  (MRIT-L) ;  a  three-position,  small  MRIT  (MRIT-S)  consists  of  the 
two  outer  shelters  shown  in  the  figure.  Both  the  large  and  small  MRIT  provide 
a  local  data  base,  and  when  deployed  can  also  contain  the  TACOB  data  base. 

Each  also  serves  as  a  secondary  communications  center  for  tactical  collection 
system  inputs  via  AUTODIN,  and  for  the  MRITs '  communciations  with  the  MIC, 
other  MRITs,  and  remote  user  terminals. 

The  MRIT  equipment  includes  an  AN/GYQ-12  (V)  with  a  640-Kbyte  memory, 
three  67-Mbyte  disk  drives,  one  nine-track  tape  drive,  a  high-speed,  elec¬ 
trostatic  line  printer,  three  or  seven  analyst  terminals,  a  CALCOMP  990  high¬ 
speed  plotter,  an  AUTODIN  interface  terminal,  and  high  security  communications 
equipment . 


Remote  Terminals 

In  addition  to  equipment  housed  in  the  MIC  and  MRIT  shelter  complexes, 
the  FMS  also  provides  support  to  remote  terminals.  Currently,  these  ter¬ 
minals  are  located  at  V  and  VII  Corps,  and  at  PCAC,  66th  MI,  the  U.S;  command 

4 

in  Berlin,  and  the  USAREUR  Systems  Division.  Other  remote  terminals  can  be 
added  as  needed,  because  each  MRIT  is  capable  of  supporting  up  to  ten.  Figure 
3  shows  the  functional  interrelationships  of  the  system  components. 

SU  1652  Users  Terminal 

Of  greatest  importance  to  this  contract  is  the  hardware  with  which  users/ 
operators  communicate  witn  the  system.  The  bulk  of  that  communication  takes 
place  through  OS-389 (V)/G  intelligent  terminals  in  the  Sperry  Univac  type 
SU  1652  configuration. 

The  SU  1652  user  terminal  contains  dual  screen  CRT 
displays,  a  light  pen  on  the  right  side,  an  alpha¬ 
numeric  keyboard  and  two  types  of  function  keys: 

Fixed  Function  Keys  (FFKs)  and  Variable  Function 
Keys  (VFKs ) .  The  FFKs  are  divided  into  three 


4/ 

IISS  User's  Manual,  Figure  2-1,  page  2-6. 
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MRIT-L  MIC  MRIT-S 


groups,  known  as  the  upper,  left  and  right  FFKs, 
all  positioned  around  the  alphanumeric  keyboard. 

The  variable  function  keys  (VFKs)  are  located  cn 
pads  on  each  side  of  the  left  and  right  FFKs.  The 
term  variable  in  VFKs  means  the  key  can  be  either 
on  or  off,  indicated  by  a  panel  light  next  to  the 
key.  Note  that  the  left  and  right  FFKs  are  dif¬ 
ferent  from  the  VFKs  in  that  they  have  no  on/off 
indicators  and  are  always  active.^ 

The  two  CRT  displays  are  subdivided  into  screen  areas  (SA) .  These  are 

SA-1  1  line  on  the  top  of  the  left  screen  for  classifica¬ 

tion. 

SA-2  19  lines  in  the  middle  of  the  left  screen  used  as  the 

major  user  area. 

SA-3  4  lines  on  the  bottom  of  the  left  screen  used  for 

messages. 

SA-4  1  line  on  the  top  of  the  right  screen  for  classifica¬ 

tion. 

SA-5  19  lines  in  the  middle  of  the  right  screen  used  as 

the  major  user  area. 

SA-6  4  lines  for  Command  Line  input  a  i  output,  system 

status  messages  and  error  messages. 

The  FFKs  located  around  the  alphanumeric  keyboard  are  used  to  perform 
editing  and  data  positioning  functions  on  the  displayed  data. 

The  SU  1652  User  terminal  features  contain  editing 
capabiliites,  such  as  character  insertion  and 
deletion,  line  changes,  character  string  block 
manipulation  and  storage  of  limited  data  in  the 
terminal.  There  is  one  left  FFK,  the  "SEND  FFK," 
that  is  very  important  to  the  user.  The  SEND 
FFK  signals  the  external  system  computer  to  read 
the  data  in  the  SA  containing  the  cursor  and 
transmit  that  data  to  the  system  computer;  this 
is  how  display  data  is  transmitted  to  the  system 
computer. 


"^IISS  Users  Manual,  page  2-23. 
6/Jiid,  page  2-29. 
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The  Variable  Function  Keys  (VFKs)  provide  the 
user  a  means  of  making  entries  controlling  his 
interactive  terminal  environment  and  responding 
to  FMS  prompts.  A  VFK  is  active  when  the  light 
indicator  is  on.  Typically,  the  pattern  of  active 
keys  on  the  left  and  right  pads  can  change  as  a 
user  proceeds  through  a  menu  option. 

There  are  several  other  pieces  of  hardware  with  which  the  user  may 
interact  at  times.  These  include  a  line  printer  and  a  plotter.  The  other 
hardware  such  as  the  disk  and  tape  drive,  the  computer,  the  crypto  units 
and  AUTODIN  terminal  are  not  used  by  the  analyst  user/operator.  Therefore, 
only  the  interactions  with  the  user  terminal  will  be  considered  in  this 
report . 


USER/OPERATOR  CONFIGURATIONS 

Unlike  many  Army  battlefield  automated  systems,  the  IISS  FMS  presently 

does  not  support  complexes  of  users/operators  performing  widely  varied  func- 

8 

tions  at  distinctively  different  terminals.  For  example,  TACFIRE  supports 
Forward  Observers,  Fire  Control  Officers,  and  Artillery  Intelligence  Officers, 
to  list  only  three  users/operators.  These  individuals  perform  functions  as 
varied  as  fire  mission  requests  and  artillery  target  intelligence  assessment, 
using  terminals  as  "dumb"  as  the  DMD  and  as  "smart"  as  the  VFKED.  By  contrast, 
virtually  every  user/operator  of  the  FMS  is  an  intelligence  analyst,  perform¬ 
ing  intelligence  functions  at  an  SU  1652  terminal.  While  there  is  a  capa¬ 
bility  for  passing  messages  from  one  user  to  another,  the  great  bulk  of  e.  a 
involves  the  user/operator  interacting  with  one  or  more  intelligence  data 
bases . 

This  is  not  to  say  that  the  scope  of  activities  carried  out  within  the 
intelligence  function  is  simple  or  stereotyped.  Indeed,  these  activities 
are  so  varied  and  complex  that  they  cannot  be  characterized  adequately  in  a 
preliminary  analysis  of  the  system.  A  single  example  of  a  series  of  user/ 


7/ 

'ibid,  page  2-34. 

8  / 

' There  is,  however,  no  intrinsic  reason  why  it  could  not  do  so,  should 
the  necessity  arise. 
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operator  transactions  will  suffice  to  illustrate  this  point.  Consider  a  user/ 
operator  who  wishes  to  perform  a  series  of  operations  on  the  Ground  Order-of- 
Battle  section  of  the  TACOB  data  base. 

The  first  step  is  to  LOGON  to  the  user  terminal  (Figure  4) .  Next,  the 
MASTER  MENU  is  selected.  Then  the  classification  and  a  caveat  are  entered 
using  the  MARK  operation.  The  user/operator  then  returns  to  the  MASTER  MENU 
and  performs  the  G1M  selection.  A  DATA  BASE  SIGNON  to  the  TACOB  data  base 
is  performed  next.  From  the  G1M  MENU  the  specific  files  to  be  accessed  are 
chosen.  The  file  relationships  for  creation,  index,  retrieval,  translation, 
and  validation  available  to  the  user/operator  at  this  point  are  illustrated  in 
Figure  5.  After  all  desired  work  has  been  done,  the  operator  performs  a 
SIGNOFF  from  G1M  followed  by  a  LOGOFF  from  the  system. 


DESIGN  FEATURES 

The  IISS  FMS  provides  a  number  of  design  features  that  are  useful  to  the 
user /operator .  For  example,  the  Fixed  Function  Keys  (FFK)  and  Variable 
Function  Keys  (VFK)  permit  the  user/operator  to  enter  a  variety  of  commands 
with  a  single  keystroke,  rather  than  laboriously  typing  them  in.  Another 
example  is  the  data  management  system's  capability  to  accept  a  single  command 
from  the  user/operator  and  then  to  update  or  retrieve  data  from  every  related 
file,  rather  than  requiring  him  or  her  to  repeat  the  command  one  or  more 
times,  specifying  a  different  related  file  each  time. 

On  the  other  hand,  some  of  the  FMS's  design  features  could  affect  the 
user's/operator's  transactions  with  the  system.  Examples  of  these  design 
features  are  presented  below. 

a.  Data  Base  Updates 

Design  feature:  The  FMS  provides  several  different 
methods  for  updating  the  data  codes  within  a  file. 


9/ 

IISS  C-  ftware  Operations  Manual. 
Group,  Document  No.  28503-W093-RU-00. 
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Figure  5.  Ground  Order -of -Battle  File  Relationships  for 
Validation,  update,  Retrieval,  and  Translation 
(Reproduced  from  IISS  TACOB  Data  Base  User  Guide. 

TRW  Defense  and  Space  Systems  Group,  Document  No. 
28503-W100-RV-00,  15  May  1979,  Figure  3.2.1,  page  16.) 
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Transactional  implication:  Generally  only  one  specific 
updating  method  is  associated  with  any  particular  given 
code;  attempts  to  use  other  methods  result  in  errors. 

Predicted  transactional  problem:  The  FMS  contains  more 
than  100  data  codes;  associating  the  correct  updating 
method  with  each  code  imposes  a  considerable  memory 
load  on  the  user/operator. 

Detection/revocation  of  problem:  The  computer  will 
detect  attempts  to  use  incorrect  updating  methods 
and  will  return  an  error  message. 

Consequences  of  the  problem:  The  user/operator  will 
require  time  to  look  up  the  correct  method,  or  to 
derive  it  from  error  messages.  In  either  case, 
updating  time  will  be  extended,  thereby  reducing 
the  overall  rate  at  which  intelligence  can  be  pro¬ 
cessed.  The  flow  of  intelligence  to  the  commander 
could  be  reduced  sufficiently  to  make  more  difficult 
his  tactical  decisions. 

Recommended  resolution:  Develop  a  uniform  user/ 
operator  procedure  for  updating  data  codes. 


b .  Updating  Multivalued  Fields 

Design  feature:  Many  of  the  fields  in  the  TACOB  data  base 
files  are  multivalued  fields.  During  updating  functions, 
the  user/operator  has  the  capability  to  add  new  items  to 
such  fields,  or  to  change  or  delete  existing  items.  If 
the  user  does  not  specify  particular  items  in  a  field, 
then  executing  a  CHANGE  or  DELETE  command  will  delete  all 

•  Q 

items  in  the  field. 

Transactional  implication:  In  updating  only  a  portion  of 
a  data  record,  the  user/operator  must  exercise  care  to 
specify  precisely  the  items  to  be  changed  or  deleted. 

Predicted  transactional  problem;  Failure  to  specify  pre¬ 
cisely  the  data  items  to  be  changed  or  deleted  will  result 
in  the  entire  multivalued  field  being  deleted. 

Detection/revocation  of  the  problem;  Complete  data  removal 
of  an  entire  field  is  a  legal  operation  with  the  TACOB  data 
base.  The  system  is  therefore  incapable  of  determining 
when  such  removal  constitutes  an  error.  Thus,  unless  the 
user/operator  detects  the  error  from  console  display  feed¬ 
back,  such  an  error  would  go  undetected. 
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I ISS  FMS  Software  Operations  Manual. 
Group,  Document  No.  28503-W093-RU-00. 
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Consequences  of  the  problem:  Data  base  integrity  will  be 
eroded.  Reports  may  be  prepared  which  lack  significant 
or  even  vital  information.  Thus,  the  commander  may  be 
misled — perhaps  seriously — in  the  picture  he  receives  of 
the  battlefield,  particularly  if  disrupted  communications 
prevent  contradictory  information  reaching  him  from  other 
sources . 

Recommended  resolution:  Provide  the  capability  for  the 
system  to  prompt  the  user/operator  to  ensure  that  complete 
deletion  of  a  multivalued  field  is  intended  wherever  a 
CHANGE  or  DELETE  command  is  entered  without  at  least  one 
item  name.  Alternatively,  provide  the  capability  for  the 
user/operator  to  follow  the  CHANGE  or  DELETE  command  with 
ALL  (or  A) ,  or  perhaps  FIELD  (or  F) ,  when  he  or  she  actually 
wishes  to  delete  all  items  in  the  field. 


Plotter  Output 


Design  feature:  In  preparing  a  plotter  run,  the  Army  Stan¬ 
dard  Intelligence  Plotting  System  (ASIPS)  listing  provides 
the  only  source  of  feedback  on  the  plot  preparation  run. 


Transactional  implication:  The  ASIPS  listing  was  designed 
to  be  read  by  a  technician  trained  on  the  ASIPS;  few  FMS 
users/operators  have  received  that  training. 

Predicted  transactional  problem:  Few  FMS  users/operators 
will  be  able  to  interpret  the  ASIPS  listing  properly. 

Detection/revocation  of  problem:  The  system  cannot  detect 
many  of  the  errors  that  could  be  made  on  the  ASIPS  run. 
Therefore,  unless  the  user/operator  detects  an  error  while 
proofreading  the  ASIPS  listing,  that  error  will  be  propa¬ 
gated  through  the  processing  cycle  and  affect  the  final 
plot. 

Consequences  of  the  problem;  At  best,  only  the  time  required 
to  redo  the  processing  cycle  would  be  lost.  At  worst,  the 
plot  would  be  missing  information  (or  contain  erroneous 
information)  critical  to  the  individual  requesting  the  plot. 
This  could  result  in  bad  decisions  being  made  in  critical 
battlefield  situations. 

Recommended  resolution;  Rewrite  the  ASIPS  report  generator 
to  make  it  interpretable  by  the  intelligence  analyst  user/ 
operator  on  the  FMS. 


d. 


Sanitization  Software 


Design  feature:  Production  of  a  sanitized  intelligence 
report  requires  a  sequence  of  procedures;  one  or  more 
command  statements  controls  each  procedure,  and  inter¬ 
mediate  output  is  produced  by  each.  These  outputs  become 
inputs  to  the  next  procedure  in  the  sequence. 

Transactional  implication:  Detection  of  an  error  in  any 
one  (or  more)  of  the  sequential  procedures  requires  a 
restart  of  the  entire  sanitization  process. 

Predicted  transactional  problem;  Because  the  user/ 
operator  must  reenter  all  sanitization  commands,  addi¬ 
tional  opportunities  are  provided  to  repeat  errors  or 
to  commit  new  errors. 

Detection/revocation  of  problem:  An  error  may  be  detected 
by  the  user/operator  before  execution  of  the  command,  in 
which  case  the  screen  editor  can  be  used  to  correct  it. 

The  marine  may  detect  some  errors,  although  the  documen¬ 
tation  is  not  clear  on  this  point.  However,  other 
errors  not  specified  in  the  document  can  be  detected 
only  by  carefully  proofreading  the  sanitized  report. 

Consequences  of  the  problem;  An  error  detected  in 
proofreading  requires  rerunning  all  of  the  report  generating 
procedures,  a  time-consuming  process  which  reduces  the 
total  useful  output  per  unit  of  time.  An  undetected  error 
might  well  result  in  a  security  violation  and  almost 
certainly  would  result  in  flowed  data  being  delivered  to 
report  recipients. 

Recommended  resolution:  Modify  the  sanitization  software 
to  provide  the  following  capabilities:  (1)  save  all  of 
the  commands  that  control  each  of  the  sequential  procedures; 
(2)  save  the  intermediate  outputs  of  each  procedure,  keying 
then  to  the  associated  commands;  (3)  permit  the  user/operator 
to  call  up  the  saved  commands  for  editing  to  correct  errors; 
(4)  permit  the  user/operator  to  start  the  recovery  procedure 
at  the  point  of  the  (first)  error;  (5)  use  the  saved  inter¬ 
mediate  output  of  the  procedure  prior  to  the  point  at  which 
recovery  begins  as  input  to  the  recovery  procedure ; 

(6)  replace  subsequent  saved  intermediate  outputs  with  the 
outputs  of  the  repeated  procedures,  in  case  another  error 
must  be  corrected;  and  (7)  provide  an  easy  method  to  purge 
all  saved  outputs  once  an  acceptable  report  is  completed. 


^^IISS  Sanitization  Software  Users  Manual.  TRW  Defense  and  Space 
Systems  Group,  Document  No.  28503-W095-RU-00,  12  March  1979. 
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e. 


Menu  Selections 


Design  feature:  When  a  user/operator  wishes  to  select  a 
function  from  a  menu  displayed  on  the  teminal,  he  or  she 
first  uses  the  light  pen  to  move  the  cursor  to  the  desired 
menu  item.  The  individual  then  presses  the  "SEND"  FFK  to 
transmit  the  selection  to  the  processor. 

Transactional  implication:  The  user/operator  must  use  two 
entry  modes  (keyboard  and  light  pen)  in  coordination. 

Predicted  transactional  problem:  The  procedure  can  be  awk¬ 
ward,  and  is  inconvenient,  since  the  user/operator  must  either 
pick  up  the  light  pen,  move  the  cursor,  then  put  down  the 
light  pen  and  press  the  "SEND"  FFK,  or  else  use  two  hands  for 
the  procedure . 

Detection/revocation  of  the  problem:  Not  applicable  in 
this  situation. 

Consequences  of  the  problem:  The  principal  consequence  of 
this  design  feature  probably  is  inconvenience  to  the  user/ 
operator.  However,  when  the  analyst's  duties  require  exten¬ 
sive  use  of  the  system's  menus,  this  nominal  inconvenience 
could  become  a  significant  source  of  user  dissatisfaction 
and  frustration. 

Recommended  resolution:  Number  the  items  on  each  menu, 
and  modify  the  software  to  permit  the  user/ operator  to 
type  in  the  number  of  his  or  her  selection. 
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ISIS--In  Storage  Information  System 


ISIS— THE  IN  STORAGE  INFORMATION  SYSTEM 


PURPOSE  AND  MAJOR  FUNCTIONS 

ISIS  is  an  interactive  computer  system  which  "...allows  the  user  to 
interactively  view,  modify,  and  otherwise  reorganize  data  bases  that  are  of 
modest  size,  with  hundreds  rather  than  hundreds  of  thousands  of  data  objects."*- 
The  system  is  not  constrained  with  respect  to  application;  users  may  define  and 
utilize  information  relating  to  a  wide  variety  of  subjects.  ISIS  is  not  itself 
an  Army  battlefield  automated  system.  Rather,  it  is  a  general  purpose  file-  and 
information -handling  system,  and  could  be  widely  applicable  in  Army  BASs. 

Indeed  in  the  document  cited  above,  it  is  illustrated  in  a  tactical  command  and 
control  application. 


The  basic  functions  of  ISIS  include: 

a.  File  Definition:  naming  the  file  to  be  created. 

b.  Data  Structure  Definition:  specifying  the  sequence  and  relation¬ 
ships  of  objects  and  attributes  within  the  data  file. 

c.  Data  File  Loading:  directing  the  loading  of  a  particular  file  from 
peripheral  memory  to  main  memory. 

d.  Information  Display:  directing  specified  information  from  the 
computer's  memory  to  the  user  terminal. 

e.  File  Element  Restructuring:  resequencing  the  information  in  a  file 
on  the  basis  of  numerical,  textual,  or  symbolic  attributes. 


^Shukiar,  H.J. ,  Bush,  C.H. ,  and  Gammill,  R.C.  An  Introduction  to  the  ISIS 
Interactive  Information  System.  Report  R-2435-AF,  Rand  Corporation,  Santa 
Monica,  CA;  April  1979,  p.  v. 
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f.  Data  File  Content  Editing:  adding  to,  deleting  from,  and  altering 
the  contents  of  ISIS  data  files. 

g.  File  Manipulation  and  Editing;  .adding,  deleting,  and  moving  files. 

h.  Display  Formatting:  defining  the  position  in  which  information 
is  to  be  displayed  at  the  user  terminal. 

i.  Hierarchical  Data  Structure  Definition:  defining  superior-subor¬ 
dinate  or  "parent 1  child"  relationships  among  classes  of  data. 

j.  Data  Selection  Criteria  Specification:  identifying  characteristics 
of  data  objects  and  attributes  and  the  ways  in  which  these 
characteristics  are  to  be  used  to  determine  disposition  of  data. 

RELEVANT  HARDWARE/ SOFTWARE  ELEMENTS 

Available  ISIS  documentation  does  not  provide  much  information  on  the 
hardware  elements  of  the  system.  ISIS  was  developed  and  implemented  on  a 
Digital  Equipment  Corporation  PDP  11/70  minicomputer.  An  unspecified  terminal 
was  employed,  and  a  hard  copy  output  device  may  be  available  in  some  implemen¬ 
tations.  No  further  hardware  specification  is  available. 

ISIS  runs  under  the  UNIX  operating  system,  and  is  written  in  C,  "a 

general-purpose  programming  language ...  used  as  the  primary  programming  lan- 

2 

guage  on  the  UNIX  operating  system..."  Since  C  compilers  are  not  yet  wide¬ 
spread,  applications  of  ISIS  in  Army  BASs  may  be  limited.  Currently  C 
compilers  are  available  for  DEC  PDP-11  series  minicomputers,  the  Honeywell 
6070,  and  IBM-370  series  mainframes,  the  Interdata  8/32,  and  some  micro¬ 
processors.  The  current  paucity  of  C  compilers  does  not,  however,  limit  the 


^Aho,  A. J.  and  Ullman,  J.D.  Principles  of  Compiler  Design.  Addison-Wesley, 
Reading,  MA,  1977,  p.  557. 
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generalizability  of  ISIS  concepts,  comma'  d  language,  and  design  features.  There 
appears  to  be  no  aspect  of  ISIS  which  could  not  be  easily  implemented  in  any 
common  general-purpose  language. 

USFR/ OPERATOR  CONFIGURATIONS 

Unlike  many  Army  battlefield  automated  systems,  ISIS  presently  does  not 

support  complexes  of  users/operators  performing  widely  varied  functions  at 

3 

distinctively  different  terminals.  Purposes  of  use  may  vary,  of  course,  and 
several  persons  may  use  the  system  concurrently  through  its  time-sharing  capa¬ 
bility.  Nonetheless,  the  best  characterization  of  the  current  user/operator 
configuration  is  that  of  a  user  who  is  also  an  operator,  sitting  at  a  terminal 
and  interacting  with  a  data  base  via  ISIS  facilities. 

DESIGN  FEATURES 

ISIS  contains  a  number  of  design  features  which  make  it  ai.  attractive 
system  from  the  standpoint  of  human/computer  interaction.  These  include: 

a.  English-like  Command  Language,  which  enables  relatively  naive 
users  to  quickly  grasp  the  essential  elements  of  the  ISIS  command 
structure . 

b.  Hierarchical  Command  Complexity,  allowing  the  novice  user  to  per¬ 
form  useful  activities  with  a  relatively  simple  and  constrained 
command  set  while  at  the  same  time  permitting  the  experienced 
user  to  exercise  a  detailed  and  powerful  set  of  commands. 

c.  Use  of  "Throwaway"  Terms,  which  make  the  command  strings  more 
English-like,  but  are  ignored  by  the  computer.  The  terms  "the", 

3/ 

There  is  no  intrinsic  reason  why  it  could  not,  however. 
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"an",  and  "a"  are  examples  of  "throwaway"  terms,  so  that  the 
command  strings: 

Load  the  frags  from  the  fighter_frag  file 

and 

Load  frags  from  fighter_frag  file 
are  functionally  equivalent  in  ISIS. 

d.  Command  File  Capability,  permitting  the  ejqperienced  user  to  "pro¬ 
gram"  ISIS  operations  and  to  develop  "macro  commands."  Both  of 
these  capabilities  reduce  the  number  of  keystrokes  required  to 
perform  a  given  ISIS  operation.  This  capability  is  particularly 
useful  when  file  contents  are  volatile  but  the  operations  performed 
on  the  files  tend  to  be  repeated  periodically. 

e.  Display  Formatting,  permitting  the  user  to  organize  information 
for  display  in  the  manner  which  best  supports  a  given  task. 

f.  Information  Subsetting,  which  allows  users  to  test  information  to 
determine  whether  or  not  it  is  useful  for  a  particular  purpose 
(display,  save  in  a  file,  etc.). 

Design  Features  Affecting  User/Operator  Transactions 

Although  the  human/machine  interface  in  ISIS  is  generally  quite  good, 
some  design  features  could  affect  user/operator  transactions  with  the  machine 
components  of  the  system.  These  design  features  are  discussed  below,  in  the 
context  of  ISIS  as  a  component  of  an  Army  tactical  command  and  control  system. 

a.  Dictionaries 

Design  feature:  ISIS  provides  no  access  to  file  dictionaries, 
stored  format  dictionaries,  or  perform  file  dictionaries. 
Transactional  implication :  The  user/operator  cannot  review  lists 


of  the  data  or  display  formats  available  to  him  or  her. 


Predicted  transactional  problem;  Access  to  required  informa¬ 
tion  may  be  delayed  because  of  difficulty  in  locating  data  files. 
Detection/revocation  of  problem:  The  user/operator  may  be  forced 
to  resort  to  off-line  documentation  or  other,  more  knowledge¬ 
able  users/operators,  neither  of  which  may  be  immediately  avail¬ 
able  under  tactical  conditions.  Alternatively,  the  user/operator 
may  have  to  hunt  through  files  sequentially  to  locate  the  nec¬ 
essary  information. 

Consequences  of  problem:  Information  needed  by  the  commander 
for  tactical  decision-making  may  be  delayed.  Information  needed 
by  the  staff  to  support  the  commander's  concept  may  be  delayed. 

In  some  circumstances,  command  and  support  decisions  may  have 
to  be  made  with  less  or  lower-quality  information  than  would 
otherwise  be  available.  Depending  on  the  situation  and  other 
information  sources,  impact  on  the  success  of  the  mission  could 
be  severe. 

Recommended  resolution:  Create  separate,  on-line  file,  format, 
and  perform  file  dictionaries  which  provide  names  and  explana¬ 
tions  for  all  data  files,  display  formats,  and  program  files. 
Design  features  of  these  dictionaries  should  include: 

1.  Automatic  updating  to  reflect  effects  of  most  recent 
file  transactions. 

2.  Alphabetical  listings  of  file  names,  format  names,  and 
perform  file  names. 

3.  Redundant  alphabetical  listings  by  discrete  elements  of 
file,  format,  and  perform  file  names. 
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4.  Hierarchical  listings  by  subject. 

5.  "Back  trace"  listings  to  indicate  files,  formats,  and 
perform  files  by  specific  attributes. 

Command  Strings 

Design  feature:  ISIS  provides  no  command  function  keys  or 
command  menus.  All  commands  are  entered  as  character  strings 
by  typing  on  an  alphanumeric  keyboard.  Some  of  these  strings 
are  quite  long,  running  to  several  lines  on  the  80-character- 
per-line  display.  Each  time  the  user/operator  executes  a  carriage 
return,  ISIS  evaluates  the  just-entered  line  fcr  syntax  errors. 

If  an  error  is  detected,  ISIS  outputs  the  appropriate  message 
immediately.  The  user/operator  must  then  enter  a  period  (the 
signal  to  ISIS  that  entry  of  a  command  is  completed) ,  execute  a 
carriage  return,  and  re-enter  the  entire  command. 

Transactional  implication :  Considerable  time  can  be  wasted  in 
re-entering  commands.  User/operator  may  become  frustrated  if 
he  or  she  is  nearing  the  end  of  a  command  when  an  error  occurs 
and  is  certain  to  become  frustrated  if  more  than  one  or  two 
attempts  are  required  to  enter  the  command. 

Predicted  transactional  problem:  Access  to  required  information 
may  be  delayed  because  of  command  entry  errors.  Hightened  user/ 
operator  frustration  will  increase  the  probability  of  such  errors, 
and  may  initiate  a  vicious  cycle  of  error-frustration-error, 
etc.,  particularly  in  stresful  tactical  situations. 
Detection/revocation  of  problem:  Unless  the  terminal  has  a 
screen  editor  (which  is  not  clear  from  the  documentation) ,  the 
user/operator  is  helpless  in  this  situation.  All  errors,  whether 
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self-  or  system-detected,  force  him  or  her  to  begin  entering 


the  command  again  from  the  start. 

Consequences  of  the  problem:  Same  as  for  the  previous  design 
feature . 

Recommended  resolution:  At  present,  the  user' s /operator ’ s  only 

recourse  appears  to  be  to  exit  from  ISIS,  invoke  the  "Rand 
4  5 

Editor"  '  and  to  construct  his  or  her  command  strings  in  what 
is  called  a  "perform  file"  (a  kind  of  macro).  The  user/operator 
then  invokes  ISIS  again  and  executes  the  perform  file.  While 
this  procedure  is  acceptable  for  "programming"  command  sequences 
that  will  be  used  repeatedly,  it  is  awkward  and  time-consuming 
for  on-line,  interactive  sessions  intended  to  obtain  immediate 
results.  To  resolve  the  problem,  provide  an  editing  capability 
in  ISIS  itself  to  permit  the  user/operator  to  edit  a  single 
character,  a  word,  a  phrase,  or  an  entire  line  of  command  text. 
Also,  modify  ISIS  to  evaluate  syntax  and  grammar  character-by¬ 
character  for  syntax  errors,  and  to  allow  the  user  to  continue 
entering  the  command  from  the  end  of  the  line  in  which  the  error 
occurred, 

c.  Command  Language  Semantics 

Design  feature:  ISIS  commands  must  be  entered  in  their 
entirety;  the  system  does  not  provide  any  mnemonics  or  other 
"shorthand"  features. 


4/ 

Bilofsky,  W.  The  CRT  Text  Editor  NED — Introduction  and  Reference  Manual . 
The  Rand  Corporation,  R-2176-ARPA,  December  1977. 

5//Kelly,  J.  A  Guide  to  NED:  A  New  On-line  Computer  Editor.  The  Rand  Cor¬ 
poration,  R-2000-ARPA,  July  1977. 
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Transactional  implication:  Experienced  users/operators  value 


shortcuts  to  command  entry  and  become  impatient  when  they  are 
not  provided. 

Predicted  transactional  problem:  ISIS' s  lack  of  adaptation  to 
user/operator  experience  with  command  syntax  may  lead  from 
impatience  to  frustration,  with  an  attendant  increase  in  errors 
and  delay  in  access  to  information. 

Detection/revocation  of  problem;  While  the  experienced  user/ 
operator  can  detect  the  problem  readily,  there  is  nothing  he 
or  she  can  do  about  it. 

Consequences  of  the  problem;  In  most  situations,  the  most 
probable  consequence  is  merely  user/operator  dissatisfaction 
with  the  system.  In  some  tactical  situations,  however,  the 
consequences  could  be  the  same  as  for  the  lack  of  file,  format, 
and  perform  file  dictionaries. 

Recommended  resolution:  Provide  mnemonics  for  system  commands 

(e.g.,  AP  for  Append,  DS  for  Display,  IN  for  Insert,  etc.). 

d.  Display  Formats 

Design  feature;  In  some — though  not  all — ISIS  columnar  displays, 
only  the  left-most  column  is  justified.  Thus,  for  example,  the 
template  for  the  data  set  called  "frags"  would  be  displayed 
as  follows: 

template  for  set  frags  ( 

(unit,  symbol  ) 

(missn_no,  integer  ) 

(aircraft,  symbol  ) 

(num  ac,  integer  ) 
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(call_sign,  symbol  ) 
(tot,  time  ) 
(request_no,  text  ) 
(missn_type,  symbol  ) 
(prim_target,  symbol) 
(sec_target,  symbol  ) 
(fac_sign.  text  ) 
(ord_load,  symbol  ) 
(iff  sif  comm,  text  ) 


(ecm,  text  ) 
(remarks,  text  ) 
(aar_time,  time  ) 
(tankerjsign,  text  ) 
(aar_alt,  symbol  ) 
(aar_dur,  time  ) 
) 


Transactional  implication:  User/operator  cannot  rapidly  scan 
right-hand  columns  (for  example,  to  determine  the  type  of  data 
associated  with  a  particular  attribute  name  in  the  above 
display. )  Also,  he  or  she  is  prevented  from  easily  using 
the  lengths  of  the  character  strings  in  right-hand  columns 
as  a  searching  cue,  which  further  reduces  capability  for 
rapid  scanning. 

Predicted  transactional  problem:  User/operator  efficiency  is 
reduced,  thereby  increasing  time  to  access  required  infor¬ 


mation. 


Detection/revocation  of  the  problem:  The  user/operator  can 


readily  detect  the  problem,  but  cannot  do  anything  about  it. 
Consequences  of  the  problem:  Same  as  for  Command  Language 
Semantics  feature. 

Recommended  resolution:  Justify  all  columns  of  columnar  displays. 
Left-justify  columns  of  alpha  strings  and  right- justify  columns 
of  numeric  strings. 

Numeric  Calculations 

Design  feature:  ISIS  permits  only  integer  numerical  calcula¬ 
tions,  in  the  range  -32767  <  x  <  +32767. 

Transactional  implication:  A  numerical  calculation  may  lead 
to  underflow  or  overflow,  with  a  consequent  system  "crash." 
Predicted  transactional  problem:  The  user/operator  cannot  enter 
data  consisting  of  large  positive  or  negative  numerical  values. 
Also,  the  user/operator  cannot  demand  mathematical  operations 
that  will  result  in  large  positive  or  negative  numerical  values. 
Detection/revocation  of  the  problem:  Same  as  immediately  above. 
Consequences  of  the  problem:  A  system  crash,  of  course,  will 
prevent  any  results  from  being  obtained.  In  situations  requir¬ 
ing  entry  of  values  in  excess  of  +32767,  or  resulting  in  such 
values,  computations  will  have  to  be  performed  by  hand.  The 
result  of  sucn  a  procedure  will  be  delay  in  obtaining  needed 
information.  Thus,  the  system  cannot  meet  the  commander's 
requirement  for  breadth  of  data. 
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Recommended  resolution;  ISIS  should  use  double-precision  integer 

9  9 

arithmetic,  providing  a  range  -2.15  X  10  <  x  <  +2.15  X  10  , 

thereby  allowing  the  user/operator  greater  computational  power. 
The  use  of  floating  point  arithmetic  would  provide  even  more 
power. 

f .  Relational  Expressions 

Design  feature:  Relational  expressions  (e.g.,  less  than,  greater 
than,  etc.)  are  encoded  (e.g.,  <,  >,  etc.). 

Transactional  implication:  Users/operators  who  are  not  sophis¬ 
ticated  in  mathematics  or  ADP  operations  may  not  understand  the 
relational  expression  codes. 

Predicted  transactional  problem:  Unsophisticated  users/opera¬ 
tors  must  search  off-line  sources  for  translations  of  codes. 

They  may  also  misuse  the  codes,  as  for  example  entering  <  when 
they  intend  >. 

Detection/revocation  of  problem:  The  system  could  not  detect 
a  misuse  of  a  relational  code.  Thus,  unless  the  user/operator 
or  an  observer  detected  the  error,  it  would  go  into  the  system 
and  affect  the  output 

Consequences  of  the  problem:  An  undetected  misuse  of  a  rela¬ 
tional  expression  could  produce  radically  misleading  output. 

For  example,  a  user/operator  might  be  instructed  to  identify 
areas  of  the  battlefield  where  concentrations  of  ^nemy  tanks 
were  greater  than,  say  15.  If  he  or  she  entered  "<"  rather 
than  ">",  the  output  would  show  areas  where  the  enemy  concen¬ 
trations  were  less  than  15  tanks.  If  communications  were 
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disrupted,  the  output  might  not  be  contradicted  by  other  infor¬ 


mation  sources.  Artillery  fire,  and  perhaps  maneuver  units, 
might  then  be  directed  to  areas  where  enemy  strength  was 
lightest,  meanwhile  ignoring  those  where  enemy  strength  was 
greatest  and  therefore  most  dangerous. 

Recommended  resolution:  Provide  on-line  capability  for  users/ 
operators  to  obtain  definitions  of  relational  expression  codes 
(e.g.,  <  =  less  than,  >  =  greater  than,  a  <x<b  =  the  value  of 
x  is  between  the  values  of  a  and  b,  etc.)  Also,  provide  the 
capability  for  novice  users  to  enter  the  expanded  syntax  rather 
than  the  codes  (touch  typists  might  also  prefer  expanded  syntax, 
regardless  of  experience  level.) 
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Intelligence  System 
Intelligence  Analysis  Center 
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MAGIS  IAC— MARINE  AIR/GROUND  INTELLIGENCE  SYSTEM 
INTELLIGENCE  ANALYSIS  CENTER 


PURPOSE  AND  MAJOR  FUNCTIONS 

The  MAGIS  IAC  "...is  the  first  true,  all  source  facility  ever  employed 
in  tactical  intelligence."1  The  IAC  will  "...provide  an  all  source  intelli¬ 
gence  data  base  together  with  functional  computer  programs  to  assist  the 
Assistant  Chief  of  Staff  (AC  of  S) ,  G-2,  in  the  collection,  interpretation, 
evaluation  of  information,  and  dissemination  of  intelligence  produced  affect¬ 
ing  the  command's  areas  of  operation/interest.  The  intelligence  matters  of 
the  IAC  will  be  relevant  to  the  following  areas : 

a.  Enemy  Order  of  Battle. 

b.  Target  Intelligence. 

c.  Intelligence  Collection  and  Direction. 

d.  Intelligence  Reports."2 

Ultimately,  the  IAC  will  provide  the  baseline  for  development  of  the  LHA 
Intelligence  Center  (LHA-IC)  Upgrade.  This  system  will  be  used  during  the 
embarkation,  deployment,  and  landing  portions  of  an  assault  by  a  Marine  Land¬ 
ing  Force.  During  this  portion  of  the  operation,  the  MAGIS  IAC  is  not  used; 
it  becomes  operational  only  after  command  elements  move  ashore. 


RELEVANT  HARDWARE  ELEMENTS 

The  hardware  elements  of  the  IAC  are  contained  in  three  portable  shelters, 
transportable  by  medium  truck;  an  automatic  data  processing/communications 
(ADP/COM)  shelter  and  two  analyst  shelters. 


1 /standing  Operating  Procedures  (SOP)  for  the  Development  Test— Phase  11  and 
the  Operational  Test  Phase  II  of  the  Intelligence  Analysis  Center  (IAC)  in 
a  Marine  Amphibious  Force  (MAF)  Deployment.  DL-tp-01q-u2-03.  Naval  Sur¬ 
face  Weapons  Center,  Dahlgren,  Virginia,  April  1979,  page  iii. 

2 /ibid,  page  1. 
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ADP/COM  Shelter 


The  ADP/COM  shelter  houses  the  IAC'.c  main  computer,  the  AN/UYK-7,  with 
131K  bytes  of  memory  in  two  bays.  Magnetic  tape  and  disks  provide  peripheral 
storage,  and  a  plotter  and  printer  provide  graphic  and  alphanumeric  hard  copy. 
Other  equipment  in  the  shelter  provides  communication  with  the  two  analyst 
shelters  and  with  the  outside  world.  One  terminal  is  also  located  in  the 
ADP/COM  shelter  for  use  by  the  computer  operator  and  the  Log- Journal  Clerk. 


/st  Shelters 


Each  analyst  shelter  contains  a  peripheral  computer,  the  AN/UYK-20,  a 
line  printer,  communications  equipment,  and  workspace  for  four  intelligence 
analysts.  Each  analyst  is  provided  a  Query/Response  Unit  (QRU) ,  consisting 
of  a  keyboard  and  CRT  display. 


Two  versions  of  the  QRU  were  used  in  the  IAC  version  demonstrated  to  the 
COTR  and  project  personnel  during  a  visit  to  the  Naval  Surface  Weapons  Center. 
In  the  older  version,  the  screen  is  arranged  vertically,  while  in  the  newer 
version,  the  screen  arrangement  is  horizontal.  Both  versions  contain  a 
standard,  44-key  QWERTY  keyboard,  cursor  control  keys,  and  several  groups 
of  fixed  function  keys.  Though  the  arrangements  of  the  screens  and  the 
fixed  function  keys  differ  in  some  details,  the  two  versions  of  the  QRU  are 
functionally  identical.  Also,  whether  arranged  vertically  or  horizontally, 
the  display  screen  may  be  used  as  a  single  large  screen  or  as  two  smaller 
screens.  Thus,  the  analyst  has  a  relatively  large  working  area  when  he  or 
she  is  interacting  with  the  data  base,  and  can  use  the  split  screen  feature, 
when  composing  reports,  to  call  up  information  required  to  fill  in  report 
formats . 


USER/OPEPATOR  CONFIGURATIONS 

The  MAGIS  IAC's  major  purpose  is  to  satisfy  the  intelligence  needs  of  the 
tactical  commander.  In  fulfilling  this  purpose,  it  supports  the  activities 
of  a  number  of  his  subordinates,  working  in  the  shelters. 


ADP/COM  Shelter 


Three  individuals  work  in  the  ADP/COM  shelter  (Figure  6) :  the  Watch 
Officer,  the  Log/Journal  Clerk,  and  the  ADP/COM  Operator. 

a.  Watch  Officer — The  Watch  Officer  is  in  charge  of  the  IAC,  and  exer¬ 
cises  overall  supervision  of  the  IAC  personnel  and  activities.  He  or 
she  also  has  responsibility  for  monitoring  incoming  message  traffic. 
Though  incoming  digital  intelligence  messages  are  routed  to  the 
appropriate  analysts  automatically  by  the  computer,  the  Watch  Officer 
reviews  these  messages  and  directs  any  additional  routing  he  or  she 
considers  necessary.  He  or  she  also  reviews  all  incoming  hard  copy 
and  voice  messages  for  priority  and  relevance,  and  directs  their 
entry  into  the  system  and  their  routing  to  appropriate  analysts. 

b.  Log/Journal  Clerk — The  clerk  is  responsible  for  the  Intelligence 
Journal,  in  which  is  maintained  a  record  of  all  messages  and  events 
pertinent  to  the  intelligence  section.  He  or  she  also  operates  the 
ADP/COM  shelter's  QRU,  under  the  direct  supervision  of  the  Watch 
Officer,  to  enter  hard  copy  and  voice  messages  into  the  system  and 
to  perform  necessary  message  routing  procedures.  In  this  respect, 
the  clerk  is  the  interface  between  the  Watch  Officer  and  the  IAC 
system. 

c.  ADP/COM  Operator — The  operator  has  no  intelligence  analysis  responsi¬ 
bilities.  Under  direct  supervision  of  the  Watch  Operator,  he  or  she 
operates  the  main  computer  and  other  equipment  in  the  shelter,  and 
assists  the  Watch  Officer  in  determining  the  need  for  preventive 
maintenance  or  repair  maintenance. 


Analyst  Shelters 

The  lAC's  two  analyst  shelters  are  allocated  to  two  major  functions: 
order  of  battle  analysis  and  target  analysis. 


Order  of  Battle  Shelter 

The  Order  of  Battle  shelter  (Figure  7)  is  occupied  by  five  individuals 
during  IAC  operations : 

a.  Order  of  Battle  Officer — Reporting  to  the  Watch  Officer,  the  Order  of 
Battle  Officer  is  responsible  for  all  IAC  personnel  and  activities 
concerned  with  identification,  location,  strength,  command  structure, 
tactics,  and  disposition  of  the  personnel,  units,  and  equipment  of 
enemy  forces.  He  or  she  coordinates  with  the  Watch  Officer  on  the 
routing  of  digital,  hard  copy,  and  voice  messages  to  analysts  in  the 
Order  of  Battle  shelter. 
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Figure  6.  ADP/COMM  Shelter  Positional  Assignments. 


b.  Order  of  Battle  Analysts — Order  of  Battle  information,  under  the 
supervision  of  the  Order  of  Battle  Officer,  is  allocated  to  four 
intelligence  analysts  by  the  Watch  Officer  in  coordination  with  the 
Order  of  Battle  Officer.  Typically,  the  information  is  divided 
between  a  Unit  Order  of  Battle  Analyst,  an  Assistant  Unit  Order  of 
Battle  Analyst,  an  Air  Order  of  Battle  Analyst,  and  an  Electronic 
Order  of  Battle  Analyst.  The  four  analyst  stations  depicted  in 
Figure  2  are  normally  allocated  to  the  analysts  as  shown.  However, 
any  station  can  serve  any  function,  and  the  allocation  could  be 
rearranged  by  the  ADP/COM  Operator  at  the  direction  of  the  Watch 
Officer. 


Target  Shelter 

The  Target  shelter  (Figure  8)  is  essentially  identical  to  the  Order  of 
Battle  shelter,  differing  only  in  the  functions  and  personnel  assigned  to  it: 

a.  Target  Intelligence  Officer — The  Target  Intelligence  Officer  reports 
to  the  Watch  Officer,  and  is  responsible  for  all  IAC  personnel  and 
activities  concerned  with  target  intelligence  and  collections  of 
intelligence.  He  or  she  coordinates  with  the  Watch  Officer  on  the 
routing  of  digital,  hard  copy,  and  voice  messages  to  analysts  in 
the  Target  shelter. 

b.  Targets  Analyst  and  Assistant  Targets  Analyst — These  two  individuals 
are  responsible  for  all  IAC  files  concerned  with  target  intelligence, 
or  with  geographical  areas,  complexes,  or  installations  that  might  be 
used  by  friendly  forces.  Each  occupies  an  QRU  station. 

c.  Collections  Analyst — The  Collections  Analyst  actually  works  for  and 
is  directly  responsible  to  the  Collections  Officer.  However,  since 
the  analyst  is  physically  located  in  the  Targets  shelter,  he  or  she 
must  interface  and  coordinate  with  the  Targets  Officer  and  Watch 
Officer.  The  Collections  Analyst  is  responsible  for  Sensor,  Relays, 
and  Collections  files  in  the  IAC. 

d.  Reports  Analyst — The  Reports  Analyst  is  responsible  for  maintaining 
all  statistical  information  on  the  enemy,  and  for  preparing  and  dis¬ 
seminating  written  intelligence  reports,  particularly  the  Intelligence 
Summary  (INTSUM)  and  the  Periodic  Intelligence  Summary  (PERINTSUM) . 


User/Operator  Interactions 

A  wide  variety  of  interactions  can  occur  in  the  MAGIS  IAC.  Two  examples 
will  illustrate  the  diversity  of  these  interactions. 
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Data  File  Updating 

A  hard  copy  intelligence  message  arrives  at  the  ADP/COM  shelter.  The 
Watch  Officer  reviews  the  message  and  decides  that  it  contains  information 
relevant  to  both  the  Electronic  Order  of  Battle  Analyst  in  the  Order  of 
Battle  shelter  and  the  Targets  Analyst  in  the  Targets  shelter.  Under  the 
Watch  Officer's  direction,  the  Log/Journal  Clerk  enters  the  message  into  the 
computer  and  routes  it  to  the  Electronic  Order  of  Battle  Analyst's  station, 
where  it  enters  the  station's  message  queue.  When  the  message  reaches  the 
top  of  the  queue,  the  analyst  reads  and  interprets  the  message,  and  performs 
the  necessary  data  processing  procedures  to  update  the  appropriate  portions 
of  the  Order  of  Battle  files.  Assuming  a  straightforward  transaction,  the 
analyst  does  not  interact  with  the  Order  of  Battle  Officer.  Instead,  he  or 
she  sends  a  user-to-user  message  to  notify  the  Targets  Analyst  that  a  message 
is  being  sent  over.  He  or  she  then  transmits  the  message  to  the  Targets 
Analyst's  message  queue. 

When  the  message  reaches  the  top  of  the  queue,  the  Targets  Analyst  reads  the 
message,  then  talks  briefly  with  the  Targets  Intelligence  Officer  to  clarify 
its  interpretation.  The  analyst  then  performs  the  necessary  data  processing 
procedures  to  update  the  appropriate  portions  of  the  Target  Intelligence  files 
(this  may  require  access  to  parts  of  the  Order  of  Battle  files?  while  analysts 
may  write  only  in  the  files  related  to  their  areas  of  responsibility,  all  IAC 
files  are  available  to  all  analysts  on  at  least  a  read-only  basis) . 


Report  Generation 

The  Reports  Analyst  prepares  an  Intelligence  Summary  (INTSUM)  four  times 
daily.  To  gather  material  for  the  report,  the  analyst  requests  material  from 
each  of  the  other  analysts.  Each  analyst  calls  up  a  segment  of  report  for¬ 
mat  appropriate  to  his  or  her  area  of  responsibility,  and  constructs  that 
portion  of  the  report,  based  on  data  from  the  relevant  files.  The  analyst 
then  transmits  the  format  segment  to  the  Reports  Analyst.  The  Watch  Officer 
prepares  the  conclusions  paragraph  of  the  report  and  sends  it  to  the  Reports 
Analyst  via  the  Log/Journal  Clerk.  The  Reports  Analyst  consolidates  the 
various  segments,  adds  statistical  information  from  his  or  her  own  data  files, 
and  then  produces  a  draft  report  for  review  by  the  Targets,  Order  of  Battle, 
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and  Watch  Officers.  They  coordinate  changes  to  the  draft  report,  if  necessary, 
and  the  analyst  then  produces  the  final  report  and  delivers  it  to  the  Watch 
Officer. 
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DESIGN  FEATURES 

The  MAGIS  IAC  combines  elements  of  command  language  statements,  menu 
selections,  and  "fill-in-the-blank"  structured  formats.  Command  strings  are 
entered  into  a  five-line  section  at  the  top  of  the  vertical  screen,  and  at 
the  top  of  the  left  half  of  the  horizontal  screen.  User-to-user  and  error 
messages  also  appear  in  this  area.  These  command  strings  are  used  primarily 
to  manipulate  local  data  files  (as  opposed  to  manipulating  data  elements  or 
records  within  a  file).  Thus,  the  user/operator  uses  command  strings  to  con¬ 
struct  local  files  from  other  files  in  the  system,  to  retrieve  files,  to 
purge  files,  and  to  copy  files.  Menus  are  used  generally  to  select  particu¬ 
lar  functions,  such  as  query,  update,  report,  or  plot.  Menu  selection  trans¬ 
actions  therefore  constitute  a  relatively  small  portion  of  the  user's/ 
operator ' s  activities . 

Probably  the  greatest  portion  of  his  or  her  time  is  spent  in  filling  in 
preformatted  displays.  Whether  constructing  a  query  to  retrieve  data,  adding, 
changing,  or  deleting  data  to  update  a  record,  or  constructing  a  report  or 
plot,  the  user/operator  fills  in  blanks  in  the  appropriate  display,  transmits 
the  screen  contents  to  the  CPU  for  processing,  and  receives  the  output,  gen¬ 
erally  on  the  screen.  He  or  she  may,  however,  route  the  output  to  the  printer 
or  plotter,  if  desired. 

The  IAC  has  a  number  of  design  features  intended  specifically  to  help  the 
user/operator  with  data  entry.  For  example,  the  user/operator  can  press  a 
HELP  function  key  to  obtain  a  list  of  legal  entries  for  a  given  data  field. 
Also,  after  constructing  a  query,  update,  report,  or  plot  message,  the  user/ 
operator  can  save  the  message  in  his  or  her  personal  file  for  re-use  later . 
Thus,  the  IAC  user/operator  has  a  kind  of  macro  capability  that  permits  him 
or  her  to  avoid  repeating  frequently  used  procedures.  Additionally,  the  pro¬ 
vision  of  personal,  or  "shoebox,"  files  allows  the  user/operator  to  save 
procedures  and  information  of  particular  use  to  him  or  her. 
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The  designers  of  the  IAC's  newer  QRU  averted  a  possible  negative  transfer 
of  training  situation.  On  the  keyboard  of  the  older  version,  the  user  must 
begin  each  keying  transaction  by  first  pressing  a  "TYPE"  FFK,  then  typing  in 
commands  or  pressing  other  FFKs,  as  appropriate.  On  the  newer  version,  the 
necessity  for  the  "TYPE"  function,  and  consequently  the  "TYPE"  FFK,  were 
removed.  In  the  same  physical  location,  however,  the  designers  installed  a 
key  (its  label  was  not  recorded  in  available  documentation  or  notes)  which 
has  an  operational  functional  only  under  certain  conditions;  inadvertently 
pressing  the  key,  even  repeatedly,  evidently  never  constitutes  an  error. 
Therefore,  the  user /operator  trained  on  the  older  QRU,  where  he  or  she 
became  accustomed  to  pressing  the  "TYPE"  FFK  to  initiate  a  transaction,  can 
use  the  same  physical  movements  on  the  newer  version.  Though  the  first  key¬ 
stroke  is  wasted,  at  least  it  does  no  harm. 

There  are,  however,  IAC  design  features  that  could  lave  a  negative  impact 
on  user/operator  performance.  Examples  of  these  design  features  are  pre¬ 
sented  below. 

a.  Command  Area: 

1.  Design  feature:  The  top  five  lines  of  the  QRU  are  used  for  enter¬ 
ing  commands  and  receiving  user-to-user  and  error  messages.  This 
area  is  cleared  only  when  the  user/operator  takes  direct  action  to 
clear  it. 

2.  Transactional  implication :  When  entering  a  new  command  into  the 
command  area,  the  new  characters  replace  the  old,  in  effect  con¬ 
catenating  new  material  with  old  material  already  on  the  line. 

3.  Predicted  transactional  problem ;  The  user/operator  may  exper¬ 
ience  difficulty  in  locating  the  cursor  as  his  or  her  attention 
switches  from  the  entry  line  to  the  keyboard  or  hard-copy  docu¬ 
ment  and  back.  He  or  she  may  also  confuse  new  material  with  old. 

4.  Detection/revocation  of  the  problem;  The  user/operator,  par¬ 
ticularly  if  naive  or  inexperienced,  must  attend  closely  to  the 
entry  line,  to  ensure  a  proper  character  entry  sequence. 

5.  Consequences  of  the  problem:  The  user's/operator's  entry  rate 

is  slowed  and  the  probability  of  error  is  increased,  particularly 
for  naive  or  inexperienced  persons.  Entry  errors  will  force 
re-entry  of  the  command  and  further  decrease  the  volume  of  useful 
intelligence  generated  by  the  system  per  unit  of  time. 
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6.  Recommended  resolution:  Provide  a  capability  to  erase  any  line 
in  the  command  area  on  user/operator  demand,  or  when  the  user/ 
operator  enters  the  first  character  on  the  line  (provided  he  or 
she  is  not  in  screen  edit  mode) . 

b.  Validity  Checks: 

1.  Design  feature:  In  updating  the  data  base,  the  user/ operator 

may  need  to  enter  two  associated  data  items,  such  as,  for  example, 
the  code  name  for  an  aircraft  and  a  second  code  for  the  aircraft's 
operational  role.  The  system  evidently  does  not  check  the  joint 
validity  of  these  two  items. 

2.  Transactional  implication;  The  necessity  to  know,  for  example, 
aircraft  code  names  and  codes  for  aircraft  roles  imposes  a  heavy 
memory  load. 

3.  Predicted  transactional  problem;  If  the  user  calls  up  a  help  list 
of  aircraft  roles  and  their  codes,  all  possible  roles  and  codes 
are  listed,  requiring  longer  search  times  and  excessive  oppor¬ 
tunities  to  select  the  wrong  code. 

4.  Detection/revocation  of  the  problem:  The  system  checks  the 
validity  of  each  of  the  individual  entries.  Because  it  does  not 
check  their  joint  validity,  only  the  user/operator  can  detect 
such  an  error.  If  he  or  she  doesn't  detect  it  on  the  screen, 
then  the  error  will  ba  stored  in  the  data  base. 

5.  Consequences  of  the  problem;  Erroneous  entries  will  degrade  the 
integrity  of  the  data  base.  Obvious  absurdities  ultimately  will 
be  detected  by  intelligence  analysts  or  officers,  or  by  the  com¬ 
mander  (for  example,  a  FISHBED  labeled  as  an  airborne  command 
post) .  Correction  of  such  errors  nonetheless  will  consume  time 
required  for  other  procedures.  Other,  more  subtle  errors  may 
degrade  the  quality  of  intelligence  on  which  the  commander  bases 
tactical  decisions. 

6.  Recommended  resolution:  Break  up  help  lists  hierarchically.  In 
the  case  of  codes  for  aircraft  roles,  for  example,  require  the 
user/operator  to  enter  the  name  code,  then  display  only  the  codes 
for  aircraft  roles  that  legitimately  may  be  associated  with  that 
name  code. 

c.  Report  Generation: 

1.  Design  feature:  Constructing  intelligence  reports  online  by 

using  the  split  screen  capability  is  difficult  and  error  prone.3 


^Personal  communication  from  analyst  who  demonstrated  MAGIS  IAC. 
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2.  Transactional  implications :  Users/operators  typically  avoid  use 
of  split-screen  capability  in  constructing  intelligence  reports. 

3.  Predicted  transactional  problem:  Users/operators  either  print 
data  for  report  on  hard  copy  or  else  copy  it  by  hand,  then  call 
up  the  report  format  and  reenter  the  data. 

4.  Detection/revocation  of  the  problem:  Not  applicable. 

5.  Consequences  of  the  problem;  Printing  or  handwriting  hard  cop/ 
followed  by  reentry  delays  the  production  of  intelligence  reports. 
Transcription  and  omission  errors  can  degrade  the  quality  of 
intelligence  disseminated  in  reports. 

6.  Recommended  resolution :  Provide  a  capability  for  the  user/ 
operator  to  call  up  a  segment  of  the  report  format  on  one-half 
of  the  split  screen,  and  the  relevant  data  on  the  other  half. 

Also  provide  a  capability  to  indicate  portions  of  data  to  be 
moved,  areas  of  the  report  format  into  which  they  are  to  be 
moved,  and  a  command  to  execute  the  move. 
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I  1230  USARCDM  RtSERVt  CENIEr 
1  US  ARMY  S0LU1ER  SJPPURI  CtNTtR  / 

1  DIrElTORATF  OF  armor  A V 1 A  1 1  ON  AlTN:  ATZK-AAD 
I  OSAAmMC  ♦  FT.  NnOY  AVIATION  OlvlSlON 

I  USA  FORCES  COMMAND  AF1N  -  OtPtllY  C  Or  S  FOR  INTElL1GFnCE 
I  USA  FORCES  COMMAND  AFOP  -  OtPu I Y  CHIEF  OF  STAFF  FOR  OPERATIONS 
l  US  AmMY  AIR  UEF  FN$t  LCHOOL  AT  T  N  t  ATSA-UTO 
I  OIHFcTOHATE  OF  TRAINING  aitn:  AlZU-I 
1  01  REi. TORA I F  OF  COMBAT  utVLLOPMtNIS  ATTN;  ATZU»D 
1  HOOAmCOM  MARINE  CORPS  L I  A 1  SON  OF  C 

I  OtRAMTMtNT  OF  1  HE  ARMY  Us  ARMY  iNTELulGENCE  ♦  SECURITY  COMMAND 

i  army  training  Support  CENitR  / 

I  US  AmMy  SAFETY  CENTER  aTTN:  LIBRARIAN,  BLDG  4V0B 

i  usa  missile  command  aitn:  ursmi-ntn 

1  CECOw  ATTm:  OHSt'.-ILSU 
I  USA  FORCES  CUMMaND 
1  PM  ImADE  / 

I  US  MlLllARY  UIS1R1C I  OF  BASHING  I  UN  OFt  OF  EuUAL  OPPORTUNITY 
1  ARMY  1 R A  IN | NG  SURAUHT  CtN I ER  AlTN:  AT1C-SMD 
2?  ARI  i  1A1S0N  OFF  ICE 

i  7Th  «rmy  Training  cummanu 
i  HU  UsAHEUR  atTn:  OCSOPS 
I  HUOA,  UCS  STJOY  DFFICt 

I  U.s.  NAVY  TRAINING  ANALYSIS  EVALUATION  GROUP 
1  USACi.EC  ATTN:  a  I  EC-tX-E  HUMAN  FACTORS 
i  usaFmGos/tac  Senior  army  auvisuh 
1  USA  FLEClRONlC  PROVING  GHuUNU  ATTN:  SI EEP-Ml ”ES 
I  OASA  (PDA)  UEPuIy  Fur  SCltNCt  and  TECHNOLOGY 
I  OF  C  uF  NAVAL  RLStARCH  / 

I  AFHRl/LRT 
1  AF'IRi  /LRLG 
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1  A1H  pORCE  HUMAN  RESOURCES  LAB  ATTN:  AFhRL/TSR 
1  AFAMhL/BB 
1  AFAMwL/HE 

1  NAVAL  PERSONNEL  K  ANU  0  CENTER  COMMA 10  ANO  SUPPORT  SYSTEMS 
1  NAVY  PERSONNEL  M  ANO  D  CENTER  / 

1  NAVY  PERSONNEL  R  AND  0  CENTER  OIRECTDH  OF  PROGRAMS 

1  NAVY  PERSONNEL  R  ANU  U  CENTER  / 

1  US  AnMY  AVN  ENGINEERING  FLIGHT  ACTIVITY  ATTN:  DAvTE-TD 

2  OFC  uF  NAVAL  RESEARCH  PERSONNEL  ANU  TRAINING  RESEARCH  PROGRAMS 
1  NAVAL  PERSONNEL  R  ♦  D  CENTER  / 

1  OFC  oF  NAVAL  RESEARCH  PROJECT  OFFICER*  ENVIRONMENTAL  PHYSIOLOGY 
1  NAVAL  AEROSPACE  MEDICAL  RSCH  LAB  AEROSPACE  PSYCHOLOGY  DEPARTMENT 
1  USA  f RAUOC  SYSTEMS  ANALYSIS  ACTIVITY  ATTN:  ATAA-TCA 
1  HEAOuUARTERS*  COAST  GUARD  CHIEF*  PSYCHOLOGICAL  RSCH  0R 
1  USA  hESEARCH  ANO  TECHNOLOGY  LAH  / 

1  USA  ENGINEER  TOPOGRAPHIC  LABS  ATTN:  ETl-GSL 

1  USA  cNGINEER  TOPOGRAPHIC  LABS  ATTN:  STinFO  CENTER 

1  USA  ENGINEER  TOPOGRAPHIC  LABS  ATTN:  ElL-TU-S 

1  USA  MOBILITY  EQUIPMENT  R  ANU  U  COMO  ATTN:  DrDME-TQ  (SCHOOL) 

1  NIGH i  VISION  LAh  ATTN:  DRSEL-NV*SD0 
1  ATTN:  ATTG-ATB-TA 
1  USA  HUMAN  engineering  LAB 
1  USAHtL  LIAISON  Rto*  USAAVNL  / 

1  USA  MATERIEL  SYSTEMS  ANALYSIS  ACTIVITY  ATTN:  ORXSY-C 
1  USA  kESEARCH  OFC  / 

1  NAFEl  human  engineering  branch 

1  USA  ARCTIC  TEST  CEN  ATTN:  AMSTE*PL-TS 
1  USA  cOLU  REGIONS  TEST  CEN  ATTN:  STECR-OP 
)  USa  CONCEPTS  ANALYSIS  AGCY  AITNI  CSCA-RUP 

1  USA  CONCEPTS  ANALYSIS  AGCY  AT  TNJ  CSCA-JF 

1  usac«cda  attn:  atzl-cac-ic 
1  USACaCDA  attn:  atzl-cac-im 
1  USACaC  attn:  atzl-cac-ia 
1  USACaCDA  ATTn:  ATZL-CAC-A 

1  USA  ELECTRONIC  tfARFAHE  LAB  CHIEF,  INTELLIGENCE  MATER  DEVEL  ♦  SUPP  OFF 
1  USA  hSCH  UFVEl  ♦  STANUAHU1ZA  GP*  U.K. 

1  USA  hESEARCH  A No  DEVELOPMENT  LABS  CHIEF,  BEHAV  SCIENCES  DlV,  FOOU  SCl  LAB 
1  TRAJaNA  ATTN:  SAJS-OR 

1  NAVAL  AIR  SYSTEMS  COMMANU  ATTn:  AIR-S313 
1  ECOM  ATTN:  AMSEL-CT-0 
1  USACoEC  TECHNICAL  INFORMATION  CENTER 
1  USAAhL  LIBRARY 

1  USA  | RADOC  SYSTEMS  ANALYSIS  ACTIVITY  ATTN:  ATAA-SL  (TECH  LIBRARY) 

1  UNIFORMED  SERVICES  UNIT  OF  THE  HtALTH  SCI  DEPARTMENT  OF  PSYCHIATRY 
I  USA  COMPUTER  SYSTEMS  COMMAND  ATTN:  COMMAND  TECHNICAL  LIBRARY  H-9 

1  EUSTiS  dirfctorate*  usaamrul  technical  library 
1  CENTtR  FOR  NAVAl  analysis 
1  NAVAC  HEALTH  RSCH  CEN  LIBRARY 
1  NAVAL  ELECTRONICS  LAB  ATTN:  HEStARCH  LIBRARY 
1  NAVAL  PERSONNEL  R  ANU  U  CEN  LIBRARY  ATTN:  CODE  Pl06 
1  HONElWELL  INC,  SYSTEMS  AND  RESEARCH  CENTER 
1  AIR  rORCE  HUMAN  RESOURCES  LAb  ATTN:  AFHRL/OTS 
1  HQ,  eT.  HUACHUCa  ATTN:  TECH  REF  Uly 

1  USA  mCADEMy  OF  HEALTH  SCIENCES  STIMSON  LIBRARY  (DOCUMENTS) 

1  SCHOuL  OF  SYSTEMS  AND  LOGISTICS  / 

1  USAMEROC  TECHNICAL  LIBRARY 

1  DEPAmTMENT  of  The  NAVY  TRAINING  ANALYSIS  and  EVALUATION  GP 
1  USMA  DEPT  OF  BEHAVIORAL  SCI  ANU  LEADERSHIP 
1  USA  COMMAND  ANO  GENERAL  STAFF  COLLEGE  ATTN:  LIBRARY 
1  USA  (RANSPORTaTIOV  SCHOOL  USA  (HANSP  l£CH  INFO  AnO  RSCH  CEN 

1  USA  mDMINCEN  TECHNICAL  RESEARCH  BRANCH  LIBRARY 

2  HQDA  USA  MEO  RSCH  AND  DEVEL  COMMAND 
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1  USA  r IELU  ARTY  HU  / 

1  INSTITUTE  FOR  DEFENSE  ANALYSES 

1  USA  IRAINING  SURF DR T  CENTER  ATTN:  ATIC-OST-PA 
1  AFHRt  TECHNOLOGY  DFC  <H) 

1  USA  .lObILlTY  ENuI^MENT  R  AND  D  COMMAND  ATTN:  ORUmE-ZG 
1  HQ,  uSA  MDw  A  V T N :  ANPF-OE 

1  OA  Us  ARMY  RETAINING  buE  RESEARCH  ♦  EVALUATION  DIVISION 
I  USAF  SCHOOL  OF  AEROSPACE  MEDICINE  aEROMEDICAL  LlBHARy  (TSk-4) 

i  us  military  academy  oept.  of  history,  bldg  60i 
1  USA  intelligence  cen  and  sch  ATTN:  school  library 

I  USA  INTELLIGENCE  CEN  AND  SCH  aTTN;  ATSI-uP 
1  MARI.mE  CORPS  INSTITUTE 
1  NAVAL  SAFETY  CENTER  / 

T  USAAwNC  and  FT.  HJCKEH  attn:  AlZQ-ES 
1  US  AkMY  AVN  TNG  LIBRARY  ATTN!  CHIEF  ulHRARlAN 
1  USAAvNC  ATTN:  ATZQ-U 

1  US  MILITARY  ACADEMY  OIHECTOR  qF  INSTITUTIONAL  RSCH 
1  USA  «IR  DEFENSE  SCHOOL  ATTN:  ATSA-CD-Ms 
1  USAAuS-LIBRARY-DOCUMENlS 

T  USA  u 1R  DEFENSE  BDARO  atin:  files  REPOSITORY 
1  USA  INFANTRY  BOARD  ATTN:  ATZn«lB-AE 
1  USA  INTELLIGENCE  CEN  AND  SCH  aTTN:  ATSI-OT-SFL 
I  USA  ORDNANCE  cen  and  SCH  ATTN t  ATSL-TU-TAC 
I  USA  mRMuR  SCHOUL  attn:  ATZK-TU 

1  USA  mRMOR  CENTEk  UIhECTOHaTE  OF  COMBAT  DEVELOPMENTS 

i  navai  postgraduate  sch  attn:  duolEy  knox  library  (Code  1424) 

1  USA  iRANSPOHTAl ION  SCHOOL  OtPUTY  ASST.  COMMANDANT  EDUCA.  TECHNOLOGY 
1  USA  SIGNAL  SCHOOL  ANO  FI.  GORUON  ATTN:  ATZH-E? 

I  USA  aRMOH  CENTER  ♦  FT.  KNOX  OFF .CE  OF  ARMOR  FORCE  MGt  ♦  STANDARDlZA T ION 
1  CHIEl  OF  NAVAL  EUJCATION  ANO  TNU  / 

1  USA  SIGNAL  SCHOOL  ♦  ft.  GORDON  tUUCAT lONAL  TECHNOLOGY  DIVISION 
1  HU  AlC/XPTD  TRAINING  SYSTEMS  DEVELOPMENT 
S  USA  INTELLIGENCE  CEN  AND  SCH  ATTN:  ATSI-ERM 
1  US  AkMY  ARMOR  CENTER  attn:  AT/K-TD-PMU 

I  USA  wUARIERMASTtR  SCHOUL  DIRECTORATE  of  TRAINING  DEVELOPMENTS 
1  US  CuAST  GUARD  ACADEMY  / 

l  USA  IRANSPORIAI ION  SCHUOL  DIRECTORATE  OF  TRAINING  ♦  DOCTRINE 
1  USA  INFANTRY  SCHOOL  LIBRARY  / 

1  USA  INFANTRY  SLriODL  ATTNS  ATSh-I-V 
1  US  AkMY  INFANTHY  SCHUOL  ATTNJ  AISH-CD 
1  USA  INFANTRY  SLhODL  attn:  ATSh-OOT-LRU 
1  USA  INFANTRY  school  attn:  atsh-ev 

1  U$;i  nP  *  CHEM  SCH/TinG  CeN  ♦  FT.  MCCLELLAN  ATTN:  ATZN-PTS 

1  USa  «P  ♦  ChEM  Sch/TNG  CEN  ♦  FI.  MCCLELLAN  OIRi  COMBAT  DEVFLORMENT 

1  USA  *P  ♦  CHEM  SCH/TNG  CEN  ♦  FT.  MCCLELLAN  DIR.  TRAINING  DEVELOPMENT 

1  US*  mP  ♦  CHEM  SCH/TNG  CtN  ♦  FT.  MCCLELLAN  ATTN:  ATZN-MP-ACE 

1  USA  INSTITUTE  OF  ADMINISTRATION  ATTN:  RESIDENT  Training  MANAGEMENT 
1  USA  rIELO  ARTILLtPY  SCHOOL  MURHlS  SWtTT  LIBRARY 
I  US a  INSTITUTE  OF  AOM INIS  THAT  I  ON  ACADEMIC  LIBRARY 
1  USA  «AR  COLLtGt  ATTN:  LIBRARY 

1  USA  t NGINEER  SChODL  LIBRARY  ANO  LEARNING  RESOURCES  CENTER 
1  USA  mRMOR  SCHOUi.  (USARMS)  attn:  library 

i  organizational  ef fec t i venlss  cen  ♦  sch  attn:  librarian 

1  IIS  AkMY  INTF.LLlijt.NCE  CENTER  ♦  SCHOOL  ATTN:  AfSI-TP 

1  US  AkMY  INTELLIGENCE  CtwTER  ♦  SCHOOL  ATTN:  ATSI-RM-M 

T  US  AkMY  INTELLIGENCE  CENTER  ♦  SCHOOL  ATTN:  ATSI-TU-Pm 

1  US  AwMY  INTELLIGENCE  CENTER  ♦  SCHOOL  ATTN:  aTSI"CD-CS 

1  US  AkMY  INTELLIGENCE  CENlEH  ♦  SCHOOL  ATTNl  aTSI“ES 

l  uepakTmEnt  of  The  aih  Forge  atr  university  library  utc> 

1  ho  TkADOC  TRAImING  development  institute 

P  BRITISH  EMBASSY  BRITISH  DEFENCE  STAFF 
?  CANADIAN  JOINT  STAFF 
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1  COLS  (W)  LIBRARY 
I  FRENCH  ARMY  ATTACHE 

1  &USTk*AN  EMBASSy  DEFENSE*  MlLlURY  AND  AIR  ATTACHE 
3  CANauIAN  DEFENCE  LIAISON  STAFF  ATTN:  COUNSELLOR,  DEFENCE  R  AND  0 
]  ROYAt  NETHERLANDS  EMBASSY  MILITARY  ATTACHE 
1  CANAuIAN  FORCE*  BASE  CORNWALL  1 S  ATTN!  PERSONNEL  SELECTION 
P  CANAuIAN  FORCES  PERSONNEL  APPL  RSCH  UNIT 
1  ARMY  PERSONNEL  RESEARCH  ESTABLISHMENT 
1  NETHERLANDS  EMBASSY  OFFICE  OF  THE  AIR  ATTACHE 
1  1  PSiCHOLOGICAL  RESEARCH  UNIT  aTTN:  CP4-6-U  <LTc  M.  j.  ElEY) 
b  LIBRARY  OF  CONOhESS  EXCHANGE  and  GIFT  QlV 
l  OEFEwSE  TECHNICAL  INFORMATION  CEN  Ai'TN;  OTlC-ODA-p 
140  LIbRaHY  OF  CONGRESS  UNIT  DOCUMENTS  EXPEDITING  PROJECT 

i  us  guvernment  printing  ofc  library*  public  documents  department 
1  us  government  printing  ofc  library  and  statutory,  lib  oiv  tsld 

1  THE  army  LIBRARY  ATTN:  ARMy  STUDIES  SEc 
3  /  / 
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